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(54)TMe: PROCESS CONTROL SYSTEM USING A LAYERED-HIERARCHY CONTROL SIRAIEGY DISTRIBUTl^ INTO 
MULTIPLE CONTROL DEVICES 

(57) Abstract 

A process controller (100) iroplemenu smart fidd device standards ( i 32) and 
other bus-based aidiitectuxe standaids so that communications and control among 
devices are perfbnned and the standard control operations are transparent to a user. 
The process controller implementB and executes a standard set of function tdocks 
(522) or control functions defined by a standard protocol so that standard-^pe 
control is achieved with respect to non-standard-type devkres (12). The pnxress 
controller enables standanl devices (6) to implement the standard set of function 
blocks and control functions. The process controller implements an overall strategy 
as if all connected devices are standard devices by usage of a Ficldbus function 
block as a fundamental building block for control structures. Function blocks are 
defined to create control structures for all types of devices. A user defines the 
contn^ strategy by building a phnality of function blocks and control modules 
(440) and downloading or installing uscF-spedfied portions of the control strategy 
into the Fteldbus devices and the non-Fieldbus devices. Thereafter, the Fieldbus 
devices automatically perform the downloaded portions of the overall strategy 
independently of otfier portions of tiie control stategy. Hie process control system 
includes a diagnostic monitoring and display functionality for viewing, hi a coherent 
manner, diagnostic infonruition relating to a process dial operates over multiple 
devices and system components. The digital control system automatically senses when a new contitHlcr h attached to a networic and 
deteimnics the number and types of VO Ports that are attached to the new controller. The digital oontnri syston program also includes an 
automatic configaration prognm ttiat icsponds to scnsmg of a new controller by automaticany amfiguring the hiput^outpui (I/O) subsystem. 
Upon connection of die devke, die device is automatically sensed and configured using the database configuration infcmnation. witfiout 
setting of physical switches or node address Infonnation on tfie devices. Hie digital control system witii a piedetermined configuration 
automaticany senses die connection to a network of a digital device tiiat is not included in die predetermined configuration. The process 
oonlndsy^lndude8au8ermtBdiaoe(300)whic^ standard control languages and user-selection fttHn among 

die control languages. Fkom a sin^ application routing, a user selects a control tar^ge fnxn among a phirallty of control languages 
inchKling, for example. Function Blocks. Sequential Function Chaits, Ladder Logic and Stractnnl 1^ to implement a conuol stratt^. 
Hie process control system bichides an alaim and event monitoring and display system fw whkb wious usen of tiie system can easily 
prioritize die alarm and event mformation fliat is displayed. 




t 



wo 9806335 



-2- 



PCT/US98/0I573 



10 



15 



20 



30 



Systems that perform, monitor, control, and feed back functions in process control oivironments are 
lineally implemented by software written in high-level computer programming languages such as Basic, 
Fortran or C and executed on a conqratcr or amtrollcr. These high-level languages, although effective for 
process control programming, are not usually used or understood by process engineers, maintenance 
engineeis, control cngineeis, operators and supendsors. Higher level graphical display languages have been 
devdoped for such peraonnel.sttdi as commuoiis function block Thns each of the 

engjnecis, mainf ffnanr c personnel, operators, lab personnel and the like; require a giagrfiicai view of the 
elements of the process ccmtrol system that enables them to view the system in tenns rdevam to their 
responsibilities. 

For cxam^^ a process contnd program might be written in Fortran ^ 
calculate the average ofthc inputs and produce an otttpmvahie equal to the avera^ This 
program codd be tenned the AVERAGE function and may be invoked a^ 
displayfortheconirolengineas. A lineal graphical display may consist of a icctaiigularb^ 
inputs, one ouqrat, and a label designating the block as AVERAGE. A different programmay be used to 
create a graphical representation of this same function for an operator to view the avera ge value. Before the 
system is delivered to the customer, these software programs are placed into a Hbraiy of predefined uscx 
selectable features. The programs are identified by fanction blocks. A user may then invoke a function and 
select the predefined gi^hical representations to ^eate dififerent views for the operator, engineer, etc. hy 
selecting one of a plurality of function blocte from the librae 
rathCT than having to develop a conqiletely new program in Fortran, for example. 



A group of standardized functions, each designated by an associated funcUon block, may be stored in 
a control lihraiy. A deagner equ^ed with such a lihraiy can design process control solu^ 
interconnecting, on a conqmter display screen, various functions or elements selected with the function 
blocks to perform particular tasks. The nucrdprocessor or confer associates each of the functions or 
25 Clements defined by the ftmction blocks with predefined templar 

program fimctions or elements to each other according to the interconnections desired by the designer. 
Ideally, a designer could design an entire process control program using graphical views of predefined 
fbnctmns without ever writing one line of code in Fortran or other high-level programming language. 



One problem associated with the use of graphical views for process contnd programming is that 
existing systems altew onty the equipment manufectnna; not a user of this equipment, to create his om 
control fimctions. along with associated graphical views, or modify riie predefined fimctions within the 
provided Hbiaty. 

Newproocss control fimctions are designed primaiity by companies who sdl design s^ 
by the end usere wto may have a paiticular need for a fimction that is not a part irf^ th^ 
35 Actions suRdied by the conqjany. The st^^ 

fiiraished with the system to the end user, TTic end user mxBrt either utilize existing fimctions si^li^ 
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the design environment or xely on the con^^ 

particolar customized function for them. Ifthe designer is asked to modify the parameteis of the cn^neer's 
view» then all other views using those parameters have to be rewritten and modified accordingly because the 
fimction program and view pcograms are often developed independently and are not pan of an intended 
deydopmeniaivironmeni. Qcaity. such procedure is vciy cumhermme, expenslvft^ and fffngKioni ^ww^^ g 

Another problem with existing process control systems is a usage of centralized control^ typically 
employing a central controller in a network, executing a program code that is customized for specialized, 
user-d^ed control tasks. As a result, the process control systems are typically constrained to aparticular 
size and difficult to ad^ow time to arising needs. Similarly, conventional process control systems are 
iiiflexiUe in configuration, often requiring a con^lete software revisi 

devices are incoiporated. Fuithennore; the conventional process control s^ems tend tobe es^ensive and 
usually peifonn on the fiinctions initially identified by a user or a syst»n designer that are cmly altered or 
repn^grammed to perf orm new ftmctions by an eaqped who is ^miliar wi 
configur^on and programming. 

What is needed is a iiiuf<Hin or universal design enWronment that can easily be used» not only by a 
desi^ier or manufectonr but also a user, to customize an existing solution to meet his specific needs for 
developing process control functions. What is further needed is a persiHial computer-based process control 
system that is easily implemented within substantially any size process and which is updated by us^ 
without the aid of the control system designer, to perform new and different control functions. 

Many process control systems include local field devices such as valves^ motors; regulators and the 
like which are responsive to specific control protocols, such as Profibus, Fiddbus, CAN and the like, to 
implement various control function routines. Accordingly, these controllers are responsive to certain 
standard control protocols to implement control functionality in the field. The use of such standard control 
signal protocols can reduce the time and effort of developing a control system because a designer can use the 
saihe ^pes of control signals from all devices responsive to the contrd protocol 

However, certain control devices arc not responsive to standard control protocols. These devices are 
often responsive to other types of control signals such as digital ON/OFF signals, analog current signals or 
analog voltage signals. A system designer either has to avoid using field devices that arc nonresponsive to an 
instsdied protocol, or devdop systems that qierate under oiie or more protocols^ Thus, present d^ processing 
systems disadvantageous^ bck a capability to utilize both standard prc^ocol oontr^ 
do not respond to oontrd signals defined under the standard protoct^ 

What is needed is a pnxxas control system that controls both devices that are defined using a 
standard protocol and other, non-protocol devices in a maimer that is transparent to the user of the process 
control system. 
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Systems that pafom^ monitor, control, and feed back functions in pnicess control coviionments arc 
typically impionented by software written in high-level computer progiamming languages such as Basic, 
Fortnm or C and executed on a computer or controlla-. These high-levd languages, althou^ effective for 
process control programming are not usually used or understood by process cnginrm^ maimwi^^s^ 
ei|ginoers.CQntiol engineers, operators and 8iq>eiT]SQr5^ Ifigher level graphical display languages have been 
licvdtq^ for such peisomid, such as continttousfunctiQin block a^ Thus each of the 

engineer^ mainteaance personnel, operators, lab peisomid and the like, reqaiie a graphical yiew of the 
elements of the process ccmtrol system that enables them to view the s^^em in terms rdevant to their 
responsibilities. 

For cxanqde^ a foooess control program nn^ be TOittea in Fortran ^ 
caknlate the average (tftheinpids and ptoduoe an ou^mtvahie equal to the a^ This 
program could be teimed the AVEIUGE fonction and may be invdced a^ 

displ^ for the control engineers. A typcalgr^hicaldi^lay may consist ofaxeciangular block having two 
inputs, one output, and a label designating the block as AVERAGE. A different program may be used to 
create a graphical representation of this same Junction for an operator to view the average vahic. Before the 
S3fstem is delivered to the cnstcmier, these software programs are placed into a hT>raiy of predefined nser 
sdectablefeamres. lliepn^grams are identified by function blocks. Ausrarmaytheninvokcafimctionand 
select the predefined gr^hical rq>resentations to create^ different views for the operator, engineer, etc. by 
selecting one of a phualitK of fimction blocks horn the Ubraiy for use in defining a process control sofaition 
rather than having to develop a completely new program in Fortran, for example. 

A fftmp of standardized fimctions, each designated by an associated fimction block, may be stored in 
a control hbraiy. A designer equipped with such a libraiy can design process control solutions fa^ 
intevoonnecting, on a computer dispk^r screen, various fimctions or elements selected with the fimction 
blocks to perform particular tasks. The microprocessor or conymter associates each ofthefimctifms or 
elements d^ned l>y the fimction blocks with predefined templates stored in the library and relates each of the 
program fimctions or elements to each other according to the interconnections desired by the designer 
Ideally, a designer could design an entire process control program using graphical views of predefined 
fimctions without ever writing one line of code in Fortran or other high-level programming language. 

One problem associated with the use of graphical views for process control programming is that 
existing systems allow only the equipment manufectorcr, not a user of this equq)ment, to create his own 
control fimcti(ms, along with associated graphical views, or modify the predefined fimctfons within the 
provided libraiy. 

New process control fimctions are designed primarily by companies who sell deagn systems and not 
by the end users who may have a particular need for a fimction that is not a part of the sta^ 
fimctions supplied by the conqwny. The standardized fimctions arc contained within a control library 
fiimished with the system to the end user. The end user must cither utilize existing fimctions si^plied with 
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the design enWronment or idy on the ccmqniQr 

paiticular customized function for them. If the designer is asked to modify the parameters of the engineei's 
view, then all other views using those param^rs have to be rewritten and modified accordingly because the 
function program and view programs are often devdopcd indqiendcntly and are not part of an integiated 
development environment Clearly^ such procedure is veiy cumbersome^ eaqpensive^ and time-consuming. 

Another problem with esdsting process control systems Is a usage of centralized control, typicalfy 
empiqying a central controller in a network, executing a pn^gram code that is customized for spedalized, 
user-defined control tasks. As a resuh, the process control systems are ^ically constrained to aparticular 
size and difl&colt to adapt over time to arising needs. Sinoilarly, conventional process control ^erns are 
inflexibte in oonfiguratioa, <^ea leqaiiing a convlete sofhrai^ 
devices are incorporated. Furthennore, the coriventional process pontn)! systems 
usually peiform on the functions initially identified by a user or a system rfpgignw that are onfy altered or 
veprogrammed to perform new functions by an eaqiert who is fimuliar with the entire contiol gystem 

CMifigiifatifin and programnwiig 

A further problem with CTSting process control systems is that the physical inqdementation of 
different q^stems is highfy variable^ induding control devices arul fidd devices that have a wide range of 
*'intdligence" For example, some field,devices, such as valves, motors and regulators, m^ have no 
computational or control capability. Other field devices may have a high level of control autonomy. Still 
other devices may have some contputational strength, but not a suffident amount to accomplish a desired 
control ta^ 

What is needed is a mufonn or universal design ^Evinmntent that can easify 
designer or manu&ctorer but also a user» to customize a control process to the physical constraints of the 
process, utilizing control c^abilities various controllers and devices, supplementing these control c^bilities 
when desired and distributing control functionality flexibly throughout the process control system to meet 
^>ecific needs for devdoping process control functions. What is further needed is a personal conq)uter-based 
process contrd system that is easi^ iny Icmented within suhstanti a 1 ly any size process and which is iqxlated 
I7 users, withom the aid of the oonti«d system dedgn^, to perfonn new arid differs 
distributing these contrd functions throughout the control system induding all central, intermediate and 
penpheiallevds. 

Diagnostic information is one type of information that is useful to monitor and display in a process 
control systeuL However with the various types of devices in a process control system, including a wi^ 
imetyoffidddevices; diagnostic information is not generally monitored in a consistent maimer from one 
device to the next Forthennore^ important diagnostic infonnaiion typically rdates to the interaction of 
rnultq}le portions of the control system^ for exan^le, the oombined operations of a controlier and device or 
nmhiple devices and controllers. Diagnostic infoixnation relating to multiple drcnhs in a system is typ^ 
not handled by existitig process control osteons. 
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Diagnostic informadon b most uscrfbl 
occuning when the diagiwstic infold Convemional process control systems ^caUy 

aooess and display diagnostic infonnation with no idatipn to the control operations or control schemes that 
aie functioning during diagnostic testing. 

One problem associated with the use of graphical views for diagnostic displays is that existing 
systems aUow only the equipment inanu&cturer» not a user of this equipment, to define the diagnostic 
infomiiation to be monilorcd. along with assodated gc^thical views, or modify the predefined diagnostic 
imictions within the provided library. 

What is needed is a uniform or miiversal design eindronment that can easily 
designer or manufacnircr but also a user, to customize monitoring and display of diagnostic operations for a 
vaiiable number and type of devices and conqwnents of a process control system. What is further needed is a 
personal computer-based process control system that includes a flexible diagnostic monitoring and display 
iimctionali^ that is easily implemented within substantially any size process and which is updated by users, 
without the aid of the control system designer, to monitor and displ^ diagnostic infonnation for various 
combinations of process fidd devices. 

In a conventional process control system, the local field devices are ^ically configured in the field, 
often by individually programming the local field devices using a hand-held field programmer. Individual 
programming of the field devices is time consnming and ineflSdent and olten leads to inconqotibilities 
between the device configuration and the configuration of other devices and controllers in the process control 
systMn since a global view of the system is more difficult to sustain when individual devices are programmed 
independently. Usage of indi^idual programming devices is inconvenient since multiple differ«tt 
programming devices typically nnist be used to program respective different field devices. 

Furthecmoie, local device fuhires, inchiding temporuy fidhiies or local power disniptions, intenupt 
operations of the entire control ^em, sometimes causing extended downtime since each failing device must 
be reconfigured locally. 

What is needed is a process control system tiiat allows inifi vidua! field devices to be configuied 
without local, indepoidaitprogranmung. What kfmtiier needed is a process conud system which aUows 
conQgnration of the glcOial system finmi a location rmote fit>m the lo^ 

global configuration is achieved while allowing paijriieral dements which are configiffed in a suitable global 
manner, to operate independently to achieve control functionality. 

Configuration of the global system is based on parameters that describe die particular fidd devices 
that makeup the system. However, the control protocols for conununicating with the fidd devices nu^te 
insnffident to convey parameteis that arosuffidem to configore the system. Fdr exanqile, die system 
management spedfication of the Fieldbus protocol defines three slates for a device ^<^?ding an 
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INTITAUZED state, an UNINITIAUZED state, 

(SM_OPERATIONAL) state. The three defined states arc sufficient to describe the behavior of a device bom 
the perspective of the system management, but are not adequate for describing a device from the peispective 
of either the fieldbos inteilace or software engineering tools for analyzing, controlling, or displaying the 
tfatosofadevioe. This insiiffidency is highly notable when configuration involves the 
commisaoning a device that is attached to the Fiddbus link in an UNINmALIZED ^ate. 

What is fuitho^ needed is a process control system that differentiates between Fiddbus device states 
to siqyport automatic sensing of devices and online address assignment of devices. 

SevCTal control langoages have been devdoped uniter an mc-l 131 standawi whirfi yi ^^s t a ^nyj in 
implementing a control strategy. These oQntrol languages indnde fimction blocfae, gp ^umtial fiwyrH^Mi rharts, 
ladder logic and structured text Each of these languages is directed to a particular type of user, including 
control engineers, c<mtrol system deagneis, technidans, operators and maintenance workers. These nscre 
have widely different levels and areas of experience, training and expertise. Different useis typically view 
control ^^stems from greatly different pei^)ectives and sedc a solution to very dififerent problems, expressed 
iadififerem manners. For exaiiqile, a control configuration idew of a control ^em designer ma^ 
nonsense to a maintenance wodcer and vioe-veisa. 

What is needed is a user interface which flexibly presents a configuration in a manner that is most 
understandable and useful to a particular type of user. 

Alarm and event information is one type of information that is highly critical to monitor and display 
in a process control system. However with the various types of devices in a process control system, induding 
a wide variety of fidd devices, alarm infonnation is not generally monitored in a useful manner. For 
example, very different urgendes may exist with respect to a particular alarm. Some alarm conditions may 
be uuhcative merdy that^ome routine seividng should take place without urgency. Other alarm conditions 
itquire immediate attentioa GeitaiadeWces in the process control system may ineasore highly critical 
conditions while other devices monitor much less urgent information. Furthermore, important some alarm 
Gwiditions m^ rdate to information the interaction of multiple portions of the control system, for example, 
the combined operations of a controller and device or multiple devices aiul controUets. Alarm rfmHi^^yfiy 
relating to multiple drcuits and devices in a system are typically not handled by existing process control 
systems. 

Alarm and evem infonaMition is inost useful w^ien idatcd to the 
occurring when the conditions are monhored. Conveiitiorial process control systems typically access and 
display alarm information with no rdation to the control operations or control schemes that are functioning 
during diagnostic testing. Conventional process control systems generally do not have a consistent system for 
setting priority of different alarm conditions and events. 
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OneproMemassodfltedidth theuse of gi^iucal views for alaim and event displays is that existing 
^sterns allow onl^r the equipment mamiftctarer^ not a user of this cciuq)ment, to define the alarms and events 
to be momtoied, along with assodatcdgrapMcal views, or mod^ Diffa^cnt types 

afusersraa^rneedtovisDalizediffefentaqpec^ For cxam|ile, some users have 

a capability to diange only some operating a^Kcts of the These users should have access to 

condition infonnation which they can connul whUe for other events that may be controlled by another user» 
alaim information is not urgent^ needed. 

What is needed is a uniform or univeisal design environment that can easily be 
designer or manu£uinrer but also a user, to prioritize displ^ of alaim and em 

DKCLOSllRE OF INVENTION 

In accordance with the present inv^on^ a process controller in^lements smart fidd device 
standards and other bos-based architectuie standards so that communicaUons and control among devices are 
peiibrmed so that the standard control opaations are transparoit to a user. The process controller allows 
attachment to a theoretically and si*stanliaDy ualimited number and type of field devices including smart 
devices and conventional non-smait devices. Control and communication operations of the various numbeis 
and types of devices are peilbnned simultaneously and in parallel 

The described design oivironment enables a process control designer or user to modify a standard 
process control function or create a unique customized process control function and create the graphical 
views to be associated with the modified or newly created process control function, all within a common 
environment The design environment inchidcs a common interface for both the creation of the function and 
for its associated engineers, qp^tors, lab and maintenance personnel or other desired users such that when 
the engineer's fiuiction is modified or created^ the modification or creation manifests itself in all other 
graphical views of the fimction. In addition, the design environment has a common database strucuire of 
attnlmtes and methods and the graphics associated with the process con^ 

created process control functions to be rq>resented in whatever graphical methodology that is desired or 
required by the designer, whether by ladder logic, continuous fimction block or other design languages 
required by the various engineer, operator, lab, and maintenance personnel as other desired gi^hical views. 

Many advantages are adiievBd by the above-described sysXem and operating method. One advantage 
is that control operations are dispersed throu^out the control syslcm, avoiding the infleahility that arises 
firom centralized control An<^ advantage is that the control system is peisonaI<onvutCT(PQ^^ 
thocfore. inexpensive in comparison to mainfiame based systems, easily iq>giadcd as additional processes arc 
added to the system, and conveniently qpwatedtjy multiples The PC-based control is fiirther 
advantageous in aUoning nser-ftiendly programming and display platforms such as Windows 95^ and 
\71^ndowsNT>M. 
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In acoonlanceMilh the piesem invention, a processor astandard 
set of fimction blocks or control functions defined by a standard protocol so that standard-iype control is 
adueved with reqwct to non-standard-type devices. The process controller enables standard devices to 
iODplenient the standard set of function blodcs and contrcd Imictions. The process controller inqilemeats an 
5 overall strategy as if all connected devices are standard devices hy iKage nf a fiinctinn hkidc as a tfhnitamimt!^ ! 
boiiding block for control stnuHues. These function blodcs are defined to create control stnictures for aU 
^fpesfxf devices. 

Many advantages are gained by the described system and method. One advantage is that the system 
is highty uniform, whether attached devices are standard protocol devices or nonstandard devices^ therdiy 
10 inqnoving system reliMnlity. A lurther advantage is that system develi^mient costs are greatly reduced by 
handling various devices in a unifmm manner. Another advamage is that a vnd& range of diffeient field 
devices are supported so that intelligent devices utilize the intelligent capabilities and **duinb*' devices are 
controlled by other controllers. An additional advantage is that a software routine peifmning a particular 
routine is highly re-usable, improving software reliability. 

15 - In accordance with the present ifcvcntion, a process controller implements an overall, user-developed 

control strategy in a process control network that indudes distributed controller and field devices, such as 
Fieldbus and non-Incldbus devices. A liser defines the control strategy by building a plurality of function 
blodcs and control modules and downloading or installing user-specified portions of the control strate^ into 
the Fieldbus devices and the non-Fieldbus devices. Thereafter, the Fiddbus devices automatically perform 

20 thedownloadedportionsoftheoverallsttalegyindependentiyofothtf portionsofthecontrolstrategy. For 
example in a process control system |that indudes distributed fidd devices, contrdlm and workstations, 
portions of the control strategy downloaded or installed into the fidd devices operate independently of and in 
paralld with the control operations of the controllers and the woricstations, while other control qperations 
manage the Fiddbus devices and imjdement other portions of the control strategy. 

25 The descnbed process control system and operating method has riiany advantages. One advantage is 

that the system siq^es a unifonn, universal design ondronment for users of many various escpertise; 
coqierierkcearsdtraiiiing levels to custornize a cordrol process to the physicd cm A 
further advantage is that the described system uses control capabilities of various controllers and devices, 
supplementing these control equabilities when desired and distributing control functionality flexibly 

30 throughout the process control system as needed. Another advantage is that the process control system is 

easily based on a personal computer-based design which is gaieily hnplementgri within TOhjctantiaiiy any si^e * 
process and which is npdated by users, without the aid of the control system designer, to perform new and 
different control functiims. Tins flex3>jli9 is adiieved by distiibating control fimcti<ms throughout the 
ccmtrol system induding all central, intermediate and paipheral levds. 

35 In accordance with the present invention, a process control system includes a diagnostic monitoring 

and display functionality for viewing, in a coherent manner, diagnostic information relating to a process that 
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operates ever multiple devices and system compOT Ahhou^ the multiple devices and system 
camponaits typicalty encompass \wdely diflf^^ 

systan incoipQiates diagnostic infonnation relating to all devices and presents this infonnation to a systan 
user in a nmform manner so that an operating control stxategy ^ 

as though aOccmtrd actions and diagnoslicinfonnat^ A 
nser-defii^ diagncwtic program is assembled as a of function Wodcs and control modules and represented 
as a set of larjim of interconnected control objects identified as modules ivhidi include tufarmafiffnal 
stractores accessed as attributes. Infonnation is accessed using deWce hierarehy attribute addressing, 
supporting direct addressing of I/O signals ficom modules, l^passing the nse of I/O function blocks and 
avoiding I/O function blodc behavior. 

Maigr advantages arc achieved using the described iTOccss control One advantage is that 

the control scheme and the diagnostic nwjnitoiing are configured in the systto 
system rcsomces and improving system rdiability. Anotho^advantageisthat configuration of the 
diagnostics is highly vereatile, achieving a wide range of diagnostic behaviois. A further advantage is that 
the same display objecu and procedures are used to di^lay all types of information inchiding configuration 
information, status information, diagnostics and inrmany aiQr othor infonnation generated or stored in the 
system. 

In accordance with the present invention, a digital control system automatically senses when a new 
controller i$ attadied to a network and detcnnines the number and types of I/O Ports that arc attached to 
newcontroller. The digital control systra fbnnats and displays the I/O Port 

user. The digital control system program also inchides an automatic configuration program that responds to 
sensing of a new controUer by amomatically configuring the irqiut/ontp^ Theuseraddsa 
new controller without setting any physical switches or nodes. A ust^ optionaUy siqiplies configuration 
information for a device into a database, pnor to connection of a device. Upon connection of the device, the 
device is automatically sensed and configured using the database configuration information, without setting 
of physical switches on the devices. 

In accordance with another aspect of the invention, a method of automatically senring a connection 
of a controUer to a network and incorporating AecQntrofler into a netwrnkopcra^ 
stqjs of connecting a controller to the network, sending a request fi-om the controU^ to confirm a network 
address assignment, the request being accon^)anied by the controner media access contrd (MAQ address, a 
networic configuration service receiving the request to confirm and rc^nding^ The network configuration 
service reqionds by performing the steps of searching a taUe of configured devices for a matching MAC 
address and, when the MAC address matches; generating device and net^ Thedeviceand 
network information indudes a network address fixmi a device table. When the MAC address does not 
match, netwoik configuratian service generates device and network information inchiding a network address 
fimn MAC address4iased default information and adds the definilt information to the device table. When the 
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MAC address does not match, the network configoiation senice further performs the step of assigning the 
connficted oontraller under user control either as a new device added to the device table or as a device 
configaiation previously exisdng in the device table. 

Many advantage are achieved by the described system and method. One advantage is that field 
devices are ]»ogrammed from a romote location so that individual field setting of the devices, using a local 
setting device, is not necessary. Central pn)granunability is highfy useful to reduce system managemem costs 
and tor ledodQg downtime ofaprDcesscontnd system. A further advantage is that configuration of the 
entire system, rather setting of individual devices; leads to a system in which individnal ^^stem settings are 
highly conqiatible. 

In accordance with an aspect of the present invention, a control system contrds one or more 
interconnected devices according to a defined control configuration. The control system automatically senses 
a device that is connected to the control system but not induded in the connrol configuration definitioa The 
control system supplies initial interconnect information to the connected device ienflMftny to upload 
ccmfignration parametos from the device to the control system. 

In accordance with a fimher aspect of the present invention, a digital control system with a 
predetermined oonfigniation automatically senses the connection to a netwodc ctf a digital device that is not 
included in the predetermined configuration. The digital device is assigned ten^Niraiy address infoimadon 
and placed in a t^nporaiy state, called a standby state, in which the digital device siqpplies information to the 
digital control system allowing a user to access the digital (fcvicc inchiding access of device mformation and 
configuration parameters. Using the device infonnation and configuration parameters, a user selective)^ 
OHnmissions the digital device by assigning a physical device tag, and a device address, and installing a 
control strategy to the digital device, thereliy placing the digital device in an operational state in 
communication with the digital control system. In the standby state, a user intenogates to detcnnine the type 
of device that is attadi6d, determines the role of the device in the context of the. digital control system, 
assigns a physical device tag that assigns the determined role to the device^ and verifies «?TFnffiion of the 
device to the network. Also in the standby state, the user initiates other applications applied to the device, 
inchiding calibration of the device and cmtfiguiing the device within the overall control sdieme of the digital 
control system. 

In aoxirdance with another aq;)ect of the present inv^ition, a control 
i^ldbus device states beyond the states defined according to the Fieh Thecontrdl 
ig^stem sets a physical device tag equal to the device ide 

while the device is autoscnsed. A device attached to the Fieidbns link with the plgrsicd device t^^ 
to the device ID is controlled in the manner of an UNINITIALIZED device. 

In accordance with an aspect of the present inivention, automatic smsing of fidd devices is extended 
bqrond a convoitional input/ ooQmt level to the configuration of Fiddbus devices by a digital control system. 
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Maiy advantages aic achieved liy the One advantage is that 

cMifiginaUan of a control systm is greatly The physical connection of a device to the iietwo± 

artomaticalty initiates incdosion itf the 0^ 

method advantageously £ualitates confonnity between the Gonfiguration of a netwodc and the pliystca] 
inteiamnectionsoflhenetwoik that serves as the basis for the configorati^^ The described system and 
method assist programming of fidd devices from a remote location 

devices, using a local setting device, is not necessaiy. The system and method support central 
programmabUity is highly oseM to reduce system management costs and for reducing downtime of a process 
contEoi system. Afortheradvantageisthat configuration of the entire ^em, rather settii^ 
device^ leads to a system in which indrndoal system settings arc highly compatible. 

In accordance with the present invention, a process control system inchides a user inteilace whidi 
supports multiple IEC-1 13 1 standard control languages and user-selection from among the control 
languages. From a single application routine, a user seleas a control language from among a plurality of 
control langoages induding, for exan^lc, Function Blodcs, Sequential Function Charts, Ladder Logic and 
Stxucturod Text, to inclement a controi strategy. 

In accordance with another aspect of the present invention, a method for configuring a process 
control environment controlled by a computer system having a processor connected to a di^lay device 
indudes the stq) of providing a phuality of instroctional sections. An instructional section sets forth 
information relating to oonfiguiiQg the pnxxss control envhonme^ The method also indudes the steps of 
sdecting a control language editor for defining a process control environment configuration, displaying on 
the display device a seqiKince of configmation screen presentations relating to the instniction sections as 
directed in terms of the sdected control language editor, and guiding a user through the configuration of the 
process control environment via the sequence of configuration screen presentations. 

Kfany advantages are attained by the described system and inethod. One advantage is that many 
diffcrem users are supported by the system so th« 

easily use the system. Furthermore, the system is highly uscfol for a single user to tailor ^ari^ 
the system using a most appn^riate lanugo for a particular system aspect 

In accordance with the present invention, a process control syslan inchides an alarm and event 
monittMing and di^lay system for whidt various users <tf the ^em can easily prioritize the alarm and event 
information that is displayed. The alarm and event configuration is M^flexiUe and is configured b^ 
user to display particular events in a hieraiddcal manner, as directed by the user. The user sets a desired 
alarm priority, sdecting high importance alarms for more urgent display and annunciation arul tendering a 
lower display status to less urgent events. At log-on, a particular system user is associated with a diq^lay 
configuration for displaying alarm and event information that is pertinent to that usa- and the process control 
system is automatically -primed" with current alarms and initiate process inf ormati<m about new alarm and 
event occurrences. 
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Maity advantages are achfcved using the descift One advanl^ is thai 

alaraiinfoiniaii(mis presmted U>aus^wlK)canbestnse ttmtinfo in a manner directed by the user. 

Another advantage is that a user attains access to the ^propriate infonnation automatically, at log-on. A 
liuther advantage is that the infonnation stream is **piimed" wh» 
events begin immediate aoconmlation for that user. 

BRIEF DESCMPnON OF DRAWINGS 

The features of the invention believed to be novel are 
However, the invention itself both as to its structme and method of opmtion^ may best be undemood by 
rderdi^ to the folknving description and accompanying dnnvings. 

FIGURES 1 A, IB and 1 C iUustxate a screen display, a first schematic block diagram and a second 
schematic block diagram, respectively, process conUol systems in accordance with a generalized embodiment 
of the present invention which iumishes a cqiability to create a new control template and a capabili^ to 
modify an existing control ten^late for only one view, such as an engineering view. 

MGURE 2 is a schematic blodc diagram showing the process control environment in a 
confignration implementation and a ruurtime implementation. 

FIGURE 3 is a blodc diagram illustrating a user interface for usi^e with both configuration and 
luihtime models of the process control envirorunent. 

FIGURE 4 is a schematic block diagram which depicts a hierardiical relationship among system 
objects of a oonfiguiation model in accordance with an embodiment of the present irwention. 

FIGURE 5 is a schematic block diagram which depicts a configuration architecture that operates 
within the hierarchical relatitmship illustrated in FIGURE 4. 

FIGURE 6 is a block diagram ilhistiati]^ an ezanq>le of an elemental function blodc, which is one 
type of system object within the configuration model definitioa 

FIGURE 7 is a tdock diagram depicting an example of a composite function block, v^ch is another 
^ype of system object within the configuration model definition. 

FIGURE S is a block diagram Ohistrating an example of a conuoi module, whidi is another type of ' 
sjfstem object within the configuration model definition. 

FIGURE 9 is a blodc di^giam showing a module instance; spedficaify a c^ 
whidi is created in accordance with the controi inodule definition dqncted in FIGU^ 

FIGURE 10 is a flow chart vAikh shows an exanq>le of execution of a control module at nm-time. 
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FIGURE 11 is a flow chart which shows an example of a module at a highest layer of a conlio] 
stnictoie. 

FIGURE 12 is a blodc diagram which ilhistcates an olgect-oriented method for installing a process 
H> attribute block into a PIO deviccw 

FIGURE 13 is a Uock diagram dqucting an object-oriented method for linking a oontio] module 
iiqnit attribute to a PIO attribute. 

FIGURE 14 is a biodc diagram showing an cAi|ectH)rienied method for linking a control module 
ou^ attribute to aPIO attribute. 

FIGURE 15 is ablock di^^gram diowing an oljecl-ori^tiBd method for reading values of contained 
PIO attributes. 

FIGURE 16 is a blodc di^giam wbach Illustrates an organizatiDn of infonnatian for an instrument 
signal tag. 

FIGURE 17 is a flow chart illustrating a method for bootstrap loading a control system throughout 
a networic in the process control environment 

FIGURE 18 is an object communication di^igram illustrating a method for creating a device 
connection for an active, originating side of the oonnectioiL 

FIGURE 19 is an diject conmnmication diagram ilhistratiiig a method for creating a device 
connection for a passive, listening side of the oonnectiaa. 

FIGURE 20 is an object communication diagram illustrating a method for sending request/ 
response messages between devices. 

FIGURE 21 is an cbjed commw ric ation diagram iUustratiog a method of downloading a network 
oonfigDiation. 

FIGURE 22 is a inctorial view of a fiont-of-screen display which iUustiates a flowchart of the 
operations of a diagnostic display routine. 

FIGURE 23 is an object communicadon diagram illustrating a method for one device to dieck 
whether another device exists on a network. 

FIGURE 24 is an object comrnunication diagram illustrating a method for requesting device 
communications diagnostics. 
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FIGPBE 25 is an cljectoi m i mi mlcat ia n diagram 
oonnectiQn crnniinmicatiQns diagnostics. 

FIGURE 26 ilhistrates a method for automatical^ sensing and incoipoiating a contiollei/ 
miiltq[ilexernito a nm^ime system. 

FIGURE 27 is a flow cfaait illustrates steps of an automatic configuration nnitine for configuring a 
j^sysical I/O device. 

nGURE 28 is. a pictorial view of a firontHif^^men di^lay f or a gi^ 
dtsptaiying a system configuration. 

FIGURE 29 is a slate transition diagram iltustrating various states of a field device. 

FIGURE 30 is a flow chart illustrating a first operation of comnussiontng a new device. 

FIGURE 31 is a flow diart illQStrating a seocmd operation of commissioning an mdxmnd. 

FIGURE 32 is a flow chart illustrating a third op^ation-of d^c> ™n*^s?Po^«ing a device. 

FIGURE 33 is a flow diart illustrating a fourth operation of attadiing a commissioned device 
without enablement of operational powenq>. 

FIGURE 34 is a flow diart illustrating a fifth operation of replacing a device. 

FIGURE 35 is a flow chart ilhisttating a sixth operation of attaching an UNRECOGNIZED device. 

FIGURE S6 is a flow chart illustrating a seventh operation of ^jgcn mimya oning ^ti iiniw^^?^^^ 

device. 

FIGURE 37 is a flow chart illustrating an eighth operation of placing a decommissioned device in a 
standby condition. 

FIGURE 38 is a schematic blodc diagram which illustrates a progtam stnicture of a process control 
configuration program fat defining a process configuration using a |durali^ of control law gw ages. 

FIGURES 39A through 39E are multiple screen pres^itatlQiis showing configuration, selection and 
choice screens that are iiivoked by a configuration program during qierafion of a configuration q)eration 
using a functiooal Uodc oontrd language and a sequential fimction chart control Uu^guage. 

FIGURE 40 is an objea model showing object relationshq>s of various objects for handling alarm 
and event fimctions. 
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FIGURE 4t is a State transitiim diagim vriuch dqiicls alaim atti^^ 

FIGURE 42 is a context diagram showing a context for defining an alann event with respect to a 
control modnlcL 

FIGURE 43 is an object commnnication diagram illustiating a method for peifonmng an attribute 
wiite operation that eivokes an "in alaim" status. 

MOPES FOR CARRYING OPT THE INVENTION 

Rcfening to FIGURE lA, a control system is shown. In general, the system 1 indiudes a main 
processing device, such as personal conqrater 2, that is connected to a local area network ("LAN*) 3 via a 
local area netwoikcaid. Although any local area netwoik protocol nuQr be used, a non-proprietaiy 
inotoool is beneficial in many applications because it allows for communications with the local azea netwoik 
3. The local aiea n^woric 3 is dedicated to canying control parameters, control data and other rdevant 
infonnationconcexned in the process control system. As such, the LAN 3 may be referred to as an area 
controlled netwoik or ACN 3. The ACN 3 may be connected to other LANs Ibr Sharing infonnation and data 
via a hub or gateway without afifectittg the dedicated nature of ACN 3. 

In accordance with standard ethemet protocol, a phnality of physical devices may be connected to 
the ACN 3 at various "nodes.** EacA physical device connected to the ACN 3 is connected at a node and each 
node is sqiaratdy addressable according the LAN protocol used to implement ACN 3. 

To establish a redundant system, it may be desirable to construct ACN 3 from two or more ethemet 
qrstems such that the &ihn:e of a single ethernet or LAN system win not result in the £^ 
system. Whoi such "redundamethernets" are used the failure (tf one etheinet LAN can be detected 
ahemate ethemet LAN can be m^ped in to provide for the desired fimctionali^ of ACN 3. 

The main personal computer CPC) A forms a node on the ACN 3. The PC 2 may, for example, be 
a standard personal computer running a standard operating system such as Microsoft's Window NT system. 
Main PC 2 Is configured to generate, in ieq)onse to user input conomands, v^ 

provided via the ACN 3 to one or more local controllers identified as element 4 and 5 winch mq>lement the 
control strategy defined the control routines sdectcd and established in m^ Main PC 2 may also 
be configured to implement direct control routines on field devices such as pasaps, valves, motors and the 
like via transmissiQn across the ACN 3, rather than through a local controller 4 or 5. 

Local controllers 4 and S receive control routines and other configuration data Ihiough the ACN 3 
fiomPC2. The local controllos then generate signals ofvarions types to various field de^ 
pumps, motors, legubtorvaNes, etc.) 6 through IS wMch actually implement and perlbim physical steps in 
the field to inqilement the control qrstera established by the tontines pro^ 
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Two types of fidd devices may be connected to local controller ^ and ^ inriwiing fieM Hfjyjjcyff ^ 
throiigh 10 which are TesponsTO to specific comrolpro^ As 
those in the an will appreciate, there are standard control protocols (e.g. FiddBus) accoiding to which 
spedlic protocol instructions are provided to a protocol-friendly field devices (e.g., a Fieldbus field devices) 
will cause a controller located within the field device to iinplement a specific function correspon^g to the 
protoool fimction. Accordingly; field dadoes 6 Ihioagh 11 receive protocol specific (e.g., FiddBus) control 
ooninKinds from other the IcKsd contioileis 4 and 5 (H^the peisond 
iqyedfic fimctioa 

Also connected to local controllers 4 and 5 are nonrprotocol fidd devices 12 throng 15, which are 
refened to as non-protocol because ihcy do not indude any local processing power and can respond to direct 
control signals. Accordingly, fidd devices 12 through IS aro not capable of implementing functions that 
would be defined by specific control jnotoccd siich as the FiddBus control protocol. 

Functibnality is siqiplied to allow the non-protocol fidd devices 12 through 15 to operate as 
protocol'friendly (e.g., FieldBus q>ecific) devices 6 through 11. Additionally, this same fimctionality allows 
for the in^lementation of the protocol-specific control routines to be distributed between the local fidd 
devices 6 through 1 1, the local controllers 4 and 5 and the persoiud computer 2. 

The distribution of protocol-spedfic control routines is illustrated in more detail in FIGURE IB. 
FIGURE IB refers to one portion of the ^em shown in FIGURE 1 A, spedficalfy the personal computer 2, 
the elhemet 3, local controller 4, a smart fidd device 6 and a dumb device 12, in greater detail. 

Personal computer 2 includes program software routines for implementing standard fimctional 
routines of a standard control protocol such as the InddBus protocol Accordingly, personal computer 2 is 
programmed to recdve FiddBus commands and to implonent all of the functional routines for which a local 
fidd device having Fiddbus capabilities could implement The abili^ and steps required to program 
personal computer 2 to inqilement FiddBus block fimciioiiali^ will be dearly apparent to one of onfinary 
skill in the ait. 

Connected to personal cQnq>uter 2 by the ethemet 3 is local controller 4. Local controller 4 includes 
a central processing unit connected to a random access memoiy iduch provides control signals to configure 
the central jnocessing unit to implement s^ropiiate operational functions. A read only memoiy is connected 
- to the random access memory. Tlie read onfy memoiy is programmed to indude.contnd routines vvhich can 
^'configare the central processiiig unit to in^lemem all of the functional routines of a standard control protocol 
sudi as FiddBus. Ftisonal conqniler 2 sends signds through ethemet 3 to the local controller 4 uduch 
causes one, moro or all of the programmer routines in the read only memoiy to be transfened to the random 
access memoiy to configure the CPU to inqdcment one, moro or all of the standard control pn^ocol routines 
such as the FiddBus ronfines. 
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The smart fidd device 6 includes a central processing unit which implements certain control 
functions. If the devices is. fiir example, a FiddBus device then the central processing unit associated with 
the Md device 6 is capable of impleinenting ail of the FiddBus functionality 

Because the local controller 4 has the alnliqr to implement FieldBus specific controls, oontrolier 4 
operates so that non-protocol device 12 acts and is operated as a FiddBus device. For exan^le^ if a control 
routine is ronning either in personal conqmtcr 2 or on the CPU of local controller 4, that control routine can 
inclement and provide FieldBus commands to FiddBus device 6 and non-protocol device 12, operating as a 
Fiddbos device. Since field device 6 is a FieldBus device, device 6 receives these commands and thereby 
imitonents the control functionally dictated by those commands. Non-protocol device 12, however, worics 
in conjunction with the central ptocessing unit of local controller 4 to incitement the FiddBus requirements 

such that the local controUer in cond>ination with the fidd device implements and 
commands. 

In addition to allowing non-FieldBus device 12 to act and operate as a FieldBus device, the 
descdbed aspect allows for distribution of RddBus control routines throughout the system 1 shown in 
FIGURE 1 A. For exanqde, to the extent that a control routine initially requests fidd device 6 to implement 
more than one FieldBus control routine, the system 1 allom for control to be divided between the local 
controller 4 and the local controller 5 such that a portion of the FiddBus control routines are bdng 
in^lemcnlcd by local contraJler 5 and other FieldBus routines are implemented by the use of the FiddBus 
routines stored on local controller 4. The division of FiddBus routine implementation may allow for more 
sophisticated and faster control and more efficient utilization of the overall processing power of the system. 
Stin further, the ^ that personal conq^uter 2 has the ability to implement FiddBus control routines, the 
FiddBus routines are further distributed between the local controller 4 and the personal computer 2. In this 
manner, the system allows personal computer 2 to implement one or all of the FiddBus routines for a 
particular control algorithm. 

Still further, the system allows for the implementation of FieldBus conuols to a non-FiddBus device 
connected direcdy to the ethernet 3 through use of the FieldBus control routines stored on personal computer 
2 in the sam& manner that FiddBus routines are implemented on non-FiddBus device 1 2 through use on the 
FiddBus routines stored on local controller 4. 

Aprocess control environment 100 is shown in FIGURE IC and iUustrates a comrol environment 
for iri^ilemeniing a digital control qrstcin, process controller or the The process control environment 
100 indudes an typerator woricstation 102, a laboratory wwkstation 104, and an engineering workstation 106 
dectrically intnconnected by a local area network CIAIT) 108 for transferring and receiving data and 
contttd signals amor^ the various workstalioBs and a phixaliQr of control^ The 
wodcstations 102, 104, 106 are shown ommeaed by the LAN 108 to a phrrali^ of the controller^miltqxlexers 
110 that dectricdlyimerface between the woricslatlons and a piuraUty^^ In multiple various 
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cnibodiinents, the LAN 108 includes a sm^ tvoikstation oonneded directly to a controller/multiplexer 1 10 
or ahemativeiy indudes a plurality of woikstaiions; eacample three workstations 102, 104, 106, and many 
oontroUet^nmltiplexers 1 10 d^nding vpon the poiposes and requiiemcnts of the process control 
envinmment 100. In some embodiments, a single process controller/multiplexer 110 controls several different 
- processes 11 2 or attemativdy controls a poition of a single process. 

In the process oontn^ environment 100, aprooess control stralpgy is developed by creating a 
software control solution on the cngineeiing woikstation 106, Ibr exanq>le, and transfening the solution via 
^ the LAN 108 to the operator workstation 102, lab workstation 104, and to controller/multiplexer 110 for 
execution. The operator workstation 102 and lab workstation 104 sv^ly iTitt>rfar*> dispk^ to the 
iContrDl/nuinitor strategy implemented in the amtroDei/miiltqilexer 110 and communicates to one or more of 
• the contiolleEABniltiplexeis 110 to view the processes 112 and diange ocmtrol attribute values according to the 
lequiiements of the deagned sohition. The processes 112 are formed from one or minefield devices, which 
may be smazt fidd devices or ccmventional (non-smait) fidd devices. The process 112 is illustiativdy 
dqiicted as two Fiddbns devices 132, a HART (highway addressable remote transducer) device 134 and a 
conventional fidd device 136. 

In addition, the operator workstation 102 and lab worksUtion 104 communicate visual and audio 
feedback to the operator regarding the status and conditions of the controlled processes 112. The engmeering 
woikstation 106 indudes a central procesarig unit (CPU) 116 and a display and input/output or user-inteiiace 
device 118 sudi as a keyboard, light pen and the like. The CPl) 116 typically indudes a dedicated memory 
117. The dedicated memory 117 includes a digital control system program (not shown) that executes on the 
CPU 116 to implement control operations and functions of the process control environment 100 shown in 
FIGURE IC The q>erator woricstation 102, the lab woikstation 104 and other workstations (not shown) 
within the process control environment 100 indnde at least one central processing unit (not shown) which is 
dectiicallty connected to a display (not ^own) and a user-intei&ce device (not shown) to allow interaction 
between a user and the CPU. In one endKidiment, the process control enviroimiem 100 iiicludes works^ 
in^emented using a Motorola 6S040 processor and a Motorola 68360 commuidcations processor running in 
companion mode with the 68040 with pdsnaxy and secondary ethem^ ports driven by the 68360 processor 
(SCCl and SCC3 respectivdy). 

The process control environment 100 also indudes a template generator 124. and a control tenq>late 
library 1 23 whidi, in comlnnatiori, form a control tenqplate system 120. A control template is defined as the 
-^gnmpiag of attribute functions that are used to control a process and the m^hndnlngy iweit far a paitir^ii^r 
process control fimction, the control attributes, variables, ii^ts, and outputs for the particular function and 
the graphical views of the fonction as needed such as an engineer view and an operator view. 

The control template system 120 indudes the control tengrfaie Kbraiy 123 that mmnnmicatM yjfh 
the temfdate generator 124. The control teoqilatehlxrary 123 contains data representing sets of piedefiri^ 
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existing control tcnqjhte functions to The control tcnqilate fimctioiis arc 

the templates thai generally oome with th^^ Thetenq)late 
generator 124 is an inteifux tliat advamagcously allows a user to create new control template functions or 
nio(GfyexistiQgGQntr)d template functions. The created and modified taiq)lat6fimctions arc selectively 
straed in the contiol tempiflfft lihraiy 123. 

The tenq)late generate 114 includes an attributes and methods language generator 126 and a 
gr^hics generator 128, The attributes and methods language generator 126 sujjplies display screens that 
aUow the user to define a phirah^ <tf attnlmte functions associated wi^ 

template function or modification of a particular existing control template Innctioii, such as inputs^ ouqiuts, 
and otiter attiibutes, as weU as providing displjQT screens to ena^^ 

that perform the new or modified function to the particular contn>ltet!9]^ The graphics generator 128 
tonishcs a user exility to design gr^hi cal views to be associated with particular contiol teng^lates. A usei 
utilizes the data stored by tiie attributes and metfiods language generator 126 and tiie graphics geneiator 128 
to CQnq)letety define UieattnTmtes, methods, and gr^hical views for a cont^^ Thcdata 
rqnesenting the created control template function is generally stored in the control template Kbraiy 123 and 
is subsequently available to selection and usage by an engineer for tiie design of process control solutions. 

The process control environment 100 is implemented using an object-oriented fiamewozk. An 
objcct^ricntcd fiamewoik uses object-oriented concepts such as class hierarchies, object states and object 
behavmr. These concerts, which are briefly discussed below, are well known in the art. Additionally, an 
object-oriented fiamewoik may be written using object-oriented programming languages, such as the C++ 
programming langnage, which arc weU-known in tiie art. or m^ be writleii, as is tiie case witii die prefened 
embodiment, using a non-object programming language such as C and implementing an olject-oriented 
fiamework in that language. 

The building block of an objectroriemed fiameworic is an dbjea. An object is d^ed by a state and 
abdavior. The state ofancAgect is set forth Iqr fields of die objects Thebehaviorofano^ectissetforUiby 
mediodsoftheobjea Eac^dbjeaisaninstanceof adass, wMchproWdes^ Aclass 
d^nes zero or more fields and zero or more methods. 

Holds are data structures which contain information defining a portion of tiie state of an object 
Otgectswhidi are instances rftiie same class have tiie same fid^ However, tiie particular infonnation 
conlainedwitiiintiicfieldsoftitefll*clscanvaiyfrom^ Eadifidd can oonlam information 

that is direct, such as an im^ value, or indirect, sudi as a rdio^ 

A mediod is a collection of conqnitcr instructions whidi can be execmed in CPU 1 16 by conqmter 
system software. The instructions of a metiiod are executed, Le., tiie metiiod is performed, w^ 
lequestsfhattiieolgectforwhichtiieroetiiodisdcfinedpeitomaicmedu^ A metiiod can be performed by 
aigrobjccttiiatisamendjeroftiiedasstiimindudcstficme^ The particular object peitoming tiie 
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nicthodistherespoiuler ortheEcsp(mduig(Ayjec^ When pexfonning the method, the lesponderco^^ 
one or moie aigiunents. Le., input data, and produces zero or one result, Le^ an object returned as output 
data. The methods for a paitiadarc^jea define the behavior of that 

QassesofanobjectH)rientfidftaineiM>ik are organized in a class Meia^^ In a class hierarchy, a 
dass inherits the fidds and methods which are defined by the superclasses of that Additionally, the 
fidds and methods defined by a class are inhented by any subclasses of the da^ I.e., an instance of a 
aibdass indudes the fidds defined by the siQjerclass and can perform the m^ods de^^ 
Apoanlingty, when a method of an object is caUed, the method 
wfakh the ob^ is a mend)er or in aiQr ooe of the siqierdas^ 
When a method of an objea is caUed, process control environ 
.examiiung the class ttf the olgect and, if necessaiy, aigr superclasses of the ol^ 

A sididass may ovenide or sq)ersede a method defuution whidi is ^ 
enhance or diange the behavior of the siibdass. However, a sui)clas5 may not supeisede the signature of the 
method. The signature ofa method includes the method's idemifitf, the numb» and ^ of aigam 
vvheiher a result is retnn^ and, ifso, the Qi)e of the result The sobdass si^ersedes an inheiited method 
definition by redefining the coniputBr instructions which are carried out in performance of the method. 

Classes wludi are capabk of having instances are conaete classes. Classes which cannot have 
instances are abstract classes. Abstract dasses may ^ne fidds and methods which are inhented by 
subclasses ofthe abstract classes. Tliesubdasses of an abstract class may be other abstract dasses; however, 
ultimately, within the class hierarchy, the subdasses are concrete classes. 

All classes defined in the disdosed prefened embodiinent, except for mix-in classes which are 
described bdow, are siibdasses of a dass,ObiecL Thus, each dass that is described herdn and which is not 
a mix-in dass inherits the niethods and fidds of ckss Object. 

The process control environment 100 exists in a configuration modd or configuration 
implementation 210 and a run-time modd or run-time implementation 220 shown in FIGURE 2. In the 
configuration implementation 210, the conqxment devices, dijects, interconnections and inteirdationships 
within the process control environment 100 are defined. In the lun-time implemeittation 220, operations of 
the various con^xment devices, d>jects, interconnections and imerrdationships are pezfonned. The 
configuration implementation 210 and the lun-iime miplementatian 220 are interaHmccted downloading. 
The download language creates system objects according to definitiDns supplied by a user and creates 
instances from the sillied d^nitions. Specifically, a con^lctcly configured Device Table relating to each 
device is downloaded to all Workstations on startup and when the Device Table is changed For controllei/ 
mnhiplexcis 110, a downloaded Device Table only inchidcs data for devices for which the controllei/ 
mnllqdcxer 1 1 0 is to initiate communications based on remote module data configured and used in the 
specific amtroller/mnltiplex^ 110. The Device Taftde is downloaded to the controllei/ miiltipleK^ 
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when otfier configuiatioii data is downloaded. In addition to downloading definitions, the download 
language also uploads instances and instance values. The configuration inq)lcmcntation 210 is activated to 
execme in the nm-time implem^tion 220 uang an installation procedure. Also, netwoik conununications 
parameters are downloaded to each device when configuration data are downloaded and whoi a vahie is 
changed. 

The process control environment 100 indudes multiple subsystems with several of the subsystems 
bavir^lKith a configuration and a run^timein^lemaitadon. For exan^le, a process gt^c subsystem 230 
sillies userniefined views and operator intcifiiGtng to the a^ 

100. The process giaj^c subsystem 230 has a process graphic editor 232, a pan of the effnfignration 
imjten^tatiQn 210, and a process gcqihic viewer 234, a portion of the nm-time in^lmentation 220. The 
process graphic editor 232 is connected to the process graphic viewer 234 fay an intersubsy^ inter&ce 23 6 
in the download language. The process control environment 100 also indndes a control siib^em 240 which 
configures and installs control modules and equipment modules in a definition and module editor 242 and 
which executes the control modules and the equipment modules in a run-time controller 244. The definition 
and module editor 242 operates within the configuration implementation 210 and the run-time controller 244 
opoates within the lun-time irnplement^on 220 to supply continuous and sequencing control fimctions. The 
definition and module editor 242 is connected to the run-time contraUer 244 fay an intersubsystcm intcr&ce 
246 in the download language. The multijde sub^ems are interconnected by a subsystem interface 250. 

The configuration implementation 210 and the run-time implementation 220 interface to a master 
database 260 to support access to conunon data strucnues. Various local (non-master) databases 262 
interface to the master database 260, for example, t6 transfer configuration data from the master database 260 
to the local databases 262 as directed by a user. Part ofthe master database 260 is a persistent database 270. 
The persisted database 270 is an object which transcends tiine so that the d^^ 
the creator ofthe database no longer exists and transcends space so that the database is removable to an 
addre^ space that is different from the address space at which the dat^>ase was created. Theentire 
configuration implementation 210 is stored in the persistent database 270. 

The master database 260 and local databases 262 are accessible so that docamentation of 
configurations, statistics and diagnostics ate available for documartation purposes. 

The run-time implementation 220 interfaces to the persistent database 270 and to local databases 
262 to access data stiracturesfonned by the configiuationiriqilementation 21^ In particular, the run-time 
in^lemettfation 220 fetches selected equqmient modules, diqilays and the like from the local databases 262 
and the persistent database 270. The tunrtimeinqdememation 220 intBr£u;es to other si^ 
definitions, iheahy installing dsjetis Uiat are used to create instamxs, when the definitions do not yet exist, 
instantiating nm-time instances, and transfetring information from various source to destination objects. 
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Device Tables are eiements of the configoratiQii database it>at are local to devices and, in 
condiination, define part of the configuration inq>lementation 210. A Device Table contains information 
regarding a device in the process control environment 100. Information items in a Device Table include a 
device ID, a deWce nam^ a device type, a PCN network nnmber» an ACN segment nnmber. a simplex/ 
ledondant communication flag, a controller MAC address, a oommenl field, a primary internet protocol (IP) 
address, aprimaiy sobnet mask, a secondary IP address and a secondary subnet mask. 

Referring to FIGURE 3, a block diagram illustrates a user inlcrfece 30p for nsagc with both the 
configuration and ron-time models of the process control environment 100. Part of the user imeifaoe 300 is 
the fii^loia'™ 310, an inteifedi^ program defined under the M^ndows KT^ 
features a device-based configuration approach Another part of the u^ 
, editOT 320 for inteiCKing using a control-based configuration approach. 

TTie Explorer™ 310 is operated by a user to select, construct and operate a configuration. In 
addifion, the Eaqplorer™ 310 supplies an irutial state for navigating across various tools and processors in a 
netvvmk. A user controk the Explorer*!^ 310 to access libraries, areas, process oontrtdeqm^ 
security operations. nCURE 3 illustrates the rektionshipb^weeni^ons tools that 
ta^ operating within the process control environment 1 00 and the relationship between components of the 
process control environment 100 such as, libraries, areas, process control equqiment and security. For 
exaQq>]e, when a user selects a "show tags" function from within an area, a "tag list builder*' is displayed, 
showing a list of control and I/O flags. From the tag list builder, the user can nse an ''add tag** function to 
add a module to a list, thereby invoking a "module editor*'. 

Referring to FIGURE 4, a sdiematic blodc diagram illustrates a hierarchical relationship among 
system objects of a configuration model 400. The configuration model 400 inchides many configuration 
aspects incIudiDg control, I/O, process graphics, process equipment, alarms, histoty and events. The 
configuration model 400 also inchides a device description and network topology layout 

The configuration model hierarchy 400 is defined for usage fay a particular set of users for 
visualizing system object relati<msliips and locaticms and for communicating or navigating maintenance 
information among various ^stem objects. For example, one configuration model hierarchy 400, specifically 
a phy^cal plant hierarchy, is defined for usage by maiiitenance engiiieers and technicians for visualizing 
jrfrysica] plant relationships and locations and for communicating or navigating maintenance information 
among various iristruments and eqnq>ment in a physical plant An embodiment of a configuration model 
hifflarcfay 400 th^ fonas a physicai |rfam hierarchy sqiports a subset of the SPSS physical equipment 
standard hierarchy and inchides a configutation model site 410, one or more physical plant areas 420, 
cgo^pmem modules 430 and control inodules 440. 

The configuration model hierarchy 400 is defined for a single process site 4 10 v^ch is divided into 
one or more named idiysicalplaiu areas 420 that are defined within the configuration model hierarchy 400. 
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The physical plant areas 420 optionally contain tagged modules, each of which is uniqoely instantiated 
within the configuration modd hicraicl^ 400. A physical plant area 420 optionally contains one or more 
equipment modules 430. An equipment module 430 optionally contains other equipment modules 430, 
control modules 440 and Junction blocJcs. An equipment module 430 inchidcs and is controUcd by a control 
template that is created aooofding to (me of a mimbcr of diflfcrem graphical process control programming 
languages indudingcontmnousfiBnctionblodcJadderlogi^ The 
configuration modd hierarchy 400 optionally contains one or more control in^ A control module 
440 is contained in an object such as a phjnsical plant area 420, an equipment module 430 or another control 
module 440. A control module 440 optionally contains objccU such as other control modules 440 or fimction 
blodcs. The control module 440 is thus a container class, having instances wMch arc coU 
objects. The control module 444 is encapsulated so that all of the contents and the implementation of the 
methods of the control module are hidden. 

Refening to FIGURE 5, a schematic block diagram shows a configuration aichitectnie 500 that 
oporates within the configuration model hierarchy 400 iOustrated in FIGURE 4. The configuration 
architecture 500 indudcs a several dyccts and classes at multiple levels of abstraction. At an organizational 
levd of abstraction 510, the configuration architecture 500 inchides a site class 512 which contains "named- 
objects and classes within the configuration ardutecture 500. Named objects and classes arc definitions, 
display components sodi as screens and graphics and other items. The named d)jects and classes indude 
fimction blodcs. user accounts, modules, plant areas, events, libraries and other site-wide information. 
Examples of named items are btodc definitions, equq)mcnt modufe d^nitions, control module definitions, 
plant area names and the like. 

At a primitive levd of abstraction 520, the configuration ardiitecture 500 indudes pri^ 
define the inteifaces to functions within the configuration architecture 500. including hard-coded functions 
such as '*+^ The primitive level of abstraction 520 indudes the dasses of functions 522 and parameters 524. 
Functions 522 are operational functions at the lowest level of abstraction in the configuration architecture 
500. Functions 522 are typically coded in the Cor C++ languages. In one embodiment of the configuration 
architecture 500, the fuU set of ins)lcmcntcd fimction blocks 522 are primitives. Objects and classes at the 
primitive levd of abstraction 520 are defined throughout the site class 512. Parametcis 524 are classes and 
objects at the lowest level of abstraction in the configuration architecture. Parametere 524 include integer 
nonteis. real numbers; vectors, arrays and the Ifi^^ Attribute vahies arc mapped into parameters 524 for 
nsagewidiin a fimction Uock 522. in one embodiment, fimction blocks 522atthe ]nimitivekvdof 
abstracti<m 520 indude the function block primitives listed in TABLE I, as follows: 



TABLE L Function Blocks 







\ Action 
i ADD 


Handles sinq>le assignment statements using A defined 
expression capability. 




Sm^le Add function with extensible inputs. 
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AI 


FF Standard Analog Ii^nit 


AILite 


A scaled back version <tf the FF analog iiqmt 


AIHART 


The FF Standard Analog Input with some extra ability to 
handle HART devices. 


AND 


Sinq>]e And fonction with extensible inputs. 


AO 


FF Standard Analog Output (From FF standard specification) 


Aritlmictic 


FF Standard Arithmetic Block. (From FF standaid 
specification) 


. BDE TRIGGER 


Simple tn-diiectional edge trigger. 


filASGAIN 


FF Standard Bias/Gain. (From FF standard soecificationl 


CALOLOGIC 


Advanced calculation and logic block that its own 
language as well as the al^lity to handle single ST (1131). It 
has extensible inputs, extensible ou^nits, and the ability to 
create ten^oiaiy variables. 


Conditioii 


Handles mmplt condition statements using The defined 
expression c^ability. 


Counter 


Sinq)Ie up/down counter that handles several different 
Accumulation methods. | 


CTLSEL 


FF Standard Control Selector. (From FF standard 
specincauonj j 


DI 


rr dianaara uiscrete inpuL (rrom rr standard specification) j 


1 DlUte 


A scaled back version of the FF discrete input | 


DIVIDE 


Siitqyle Divide. " 1 


DO 


FF Standard Discrete Output (From FF standard specification) | 


DT 


FF Standard Deadtime with advanced control leseaich | 
implemented. (From FF standard specification) 


Dtol 


A boolean flan in that converts up to 16 discrete inputs to a 16- \ 
bit integer vahie. Also has some special abilities for capturing | 
input patterns. 


FILT 


Simple filter. j 


H/LMON LIMIT 


Simple higMowrignal monitor | 


INTBCSRATOR 


FF Standard Integrator block. (From FF standard | 
specification) 


ItoD 


Boolean fan-out Takes a 164)it integer and translates it into 
1 6 discfi^e rnitniitc 


L/L 


FF Standard LeadLag with 2 additional ^pes of equations to 
select (From FF standard specification) 


LOOP 


An yO and a)n[trol block with the abilities of AI, PID, and AO 
rolled into one blodc 


LOOPD 


An I/O and control blodc with the abilities of DI, Device 
Control, and DO rdled into one block. 


MAN 


FF Standard Manual Loader. (From FF standaid qjedfication) 


MULTIPLEX 


Sunple multiplexor with extensible inputs. 


MULTIPLY 


Simple multiply with extensble iiqnits. 


NDE_TRIGCER 


Simple negative edge trigger. 


NOT 


Simple not 
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OFF.DELAY 


Sinqite offikiay timer. 




Siiiq)]e oiHlelay tiiner. 


OR 


Simple logical or with extensibie ioputs. i 


P/PD 


FF Standard P/PD. (From FF standard SDcdfication) i 


, PDEjnuGGmi 


Smiple positive ifiiecdoiial edge trigger. | 


PERIOD 


Simple monitor that txiggjcrs whra an ii^mt is true for a 
spedfiedperiod | 


iPI 


FF Standard Poise liq>ut (From FF standard specification) 


PID 


FF Standaid PID with many additions indoding the ainlity to 

choose algorithm i^pe, Ibim, and slroctine. (From 17 standard 
j^yedfication) 


RAMP 


Sinq>le idmp generator. 


RAHSLIM 


Single rate limiter generator. 


{RATIO 


FF Standard Ratio blode (From FF standard ^lecification) 


IRETENnVE 


Simple retentive timer. 


RS 


Single reset dominant fi4>-flop. 


RUNAVE 


Sinq)le running average calculator. 


1 SCALER 


Simple scaler. , 


SEGC^ 


Generates square waves, sin waves, random waves, or any 
combinatioa of the three. 


SIGNALCHAR 


FF Standard Signal Characteiizer. (From FF standard 
q^edfication) 


1 SIGSEL 


Simple signal selector. 


SPLITTER 


FF Standard Splitter. (Fnrni FF standard specification) 


SR 


Single set dominam IIq>-iilop. ] 


1 SUBIRACT 


Simple subtract blodc 


TP 


Simple timed pul^ blodk. 1 


TRANSFER 


Single transfer block. 


fxOR 


Simple exclusive or block. | 



At a definition and usage level of abstraction 530, the configuration architecture 500 indudes 
definitions 532 and usages. Definitions 532 and usages, in combination, define the algorithm and the 
infeifaoe for objects indn d ing function blodcs, contra] modnles^ equipment modules, links and attnbutes. 
5 The definitions 532 define algodthms and interfaces for fimctionblodcs, modules, links and attribntes- 
Usages are objects and dasses at the definition and us^elevd of abstraction 530 that le^ 
one definition within another. 

At an instance levd of abstraction 540, the configuration ardiitecture 500 inchides instances, which 
are ^'tagged" items within the configuiadon. Phmi areas 542, modules 544, attributes 546, and PIO blocks 
10 548 are tagged instances. Instances are d^ed according to definitiims 532. A plam area 542 rq^resei^ 
geographical or logical spgnMnialionofa process site dass 512. All objects and classes at the instance levd 
of abstracticm 540 are defined fhrooghom the plam area levd so that all module in^^ 
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association with aplant area 542. To be installed in a nin-time system, the modole instances nnisl have a 1 
association^ meaning that the module is viewed as being "contained by^ or '^scoped^ i n this context of a plant 
area. A nuKhde instance 544 is an installable object that is as^ 
An attribute iiisianoe 546 is a visibte panmieter in a modide instance 544, a pla^ 

device. An attribute instance 546 may be nsed for an iiynt signal, an wnpiit rign^il 4 ^ ffftrae? ftr thg likf. 

At a device level oi abstraction S50» the configuration architecture 500 indudes devices 552 such as 
contfoOers; smait devices and consoles, and input/outpul devices (lO) 560 such as a PlOblodc, and the Mke. 
which rqnesent physical jnooess oontnil equ^mienl in the phfdcal planL A process inpnt/rmtpiit (PIO) block 
is an abstraction that iquesents various hi^ densiQf and low densi^ co nventi onal ir^mt/output devices 
inchiding Hart, FieldBus and odier iiqiut and ouQmt devim 

architecture 500. High or low density rdates to the number ofchanneJs on an I/O card. Forexanqile^S 
channels are typical on a low density card Yfidle a high density card may have 3 7 cihannete , Devices 552 are 
process control equq>mem in the configuration architecture 500 aiid include obj^ 
iiiput/<Nitput devices, consoles and the like. Input/output devices (10) 560 are the pineal piocess input and 
ou^rat devices in the configuration architecture 500. 

A smait device is a fidddeWcetlut is implemciited to transmit aikl receive digital data peitaining to 
a device, including data relating to device calibration, configuration, diagnostics and maintenance, 
l^calfy, the smart device is also adapted to transmit a standard analog signal that is indicative of various 
information including, for exanq>le, a process vahie measured fay a fidd device. Examples of smart field 
devices indudc field devices whidi follow a HART (highway addressable remote transducer) protocol, a 
Fieldbus protocol, a Modbus protocol and a device net protocol. 

Various hierarchical relationships among system objects are inqilemented to facilitate navigation 
through the process control environment 100 shown in FIGURE IC by different users and to accomplish 
different tasks. Four different hierarchical relationsh^K are defined induding control, control system, 
operations and physical plant hieiarchies. A spedfic system object may be implemented in multqile 
hiccarchical systems. 

The control hierarchy is a subset of a standard SP88 hierarchy and has system objects including site, 
plQTsical area, equipmem module, control module and control dement objects. The control hierarchy is used 
to oiganize oontnil operations and to define the scope of named obje A user interacts ivith the control 
hietaidty on the basis of a site instance, equipment module definitions, oontiQl module definitions, a plant 
area instance, equqiment module instances, control module instances, display module instances, and process 
1/0 modnleAxlock instances, having signal tags. 

The control system hierarchy indudes t^erator/oonfiguration stations, host con^uters, controllers^ 
VO devices, smart devices, gateways and the like, vrfiidi are associated using various network standards 
indu i ng area control network (ACN), pgooess control network (PCN) and other I/O network standards. In 
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one embodhnent, the ACN haxdwaie indodes standard 1 0-tese-T ethemet comiiuiiiicatioii ports and a 
wiikstation contains siaiu^ A user interacts with 

the oonnol system hieraichy oa the basis of a defined site instance, a netivoik definition, a defined netwoik 
instance, devices, and sids^ysteins such as files, caids, channels, contiolleis, operation stations, and Fieldbns 
segments. 

The area control network (ACN) indudes communication functionality at two levels, a remote object 
comnmnications (ROQ levd and a low level comnnmications level ROC level controls the interlace between 
AeI>rogiamniedqjplicationsaadtheAa«con^ The low level conmumicationssiTOort 

the intetfim wiA the TCP/IP sockets and the actual transini^ 

Remote Object Comnmnications (ROC) are system operations supporting communication of objects 
in the process control environment 100 shown in nCURE IC and particdarly supporting communication 
betvreenobjeciswhelhcrtheobjectsieadeinthcsaM The ROC communication 

level siqiports conunuiications message smices inchiding request/response, unsolicited reporting, 
event/alarm icpmtmg and broadcast message service. 

RcqucstAlesponseisa serviceby which apphcations send messages to a remote device and recdve a 
response firam the device. Unsofidlcd Reporting is a service for periodically sending updated data to a 
remote device. Unchanged data is not reported. Event/Alarm Reporting is a guaranteed delivery message 
service which is used for the transmission of events, alarms and other vital infonna!ionfi»delivciy to a 
remotedevice. The broadcast mess^e service is used to send messages to afl Program apjrfica^ 
the communications network The ROC level also sets communications polictes for the commumcaiions 
subsystem. This means that it is responsible for managing what message get sent and when as weU as how 
incoming messages are processed. Communications flow control will also be the re^nsibility of the ROC 
portion. 

Low level communications support is included for device connection management, ACN redundancy 
and comnmnications systems diagnostics. Device connection management establishes a communications 
connection between two devices and manages the transmission of messages between the two devices. ACN 
Redundancy handles the detection of communications link Mlurcs, controls the switdi irom one link to 
another and tracks the status of conununicatiQn links between a host device and connected remote devices. 
Cbmnmnicatiims subsystem diagnostics tracks canummication integrity and statistical information, responds 
to requests for communicatiims diagnostic data. 

Device connection managemcait in an ACS communications system si^rts both UDP and TCP 
^ype device amnections.UDP connections are used for normal real time data transfer TCP 
connections are used for spcdal applications using a streaming protocol sudt as file tiansfers, device flash 
downloads, and the like. Communications between devices is managed by a Device Connection Ob^ The 
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Device Connection Object transmits data and maintains the status of the commumcaticms liiiksbetmentwo 
communicating devices. 

All nonnal device connection message traffic is direaed through a single UDP conmumications 
port A Device Connection Object starts the comnrnnicattcms system by creating thft comniimirflfiim 
associated with this UDP port as weU as creating the qoeaes needed for management of the device connection 
message traffic. The Device Connection Object receives all incoming messages on a Device ComiectiQn 
conmmnicatioiis socket and routes messages to the proper device cormectioniristance for The 
Device Connection Object handles timing ftmctions of device connections, inchiding notifying device 
connection instances when messages time out waitmg to be acknowl^^ communications link 

checks ate due and when device connection resyncs have timed out 

UDP ^e communications are used for the transfer of real-tune data among devices. The lemote 
object communications (ROC) subsystem passes messages to a UDP Device Connection for transmission to a 
destination device. A pool ofmessage buffers is created on startup of each device. The message pool is used 
for all data transferred !»etween devices, preventing the communications subsystem fiom exhausting memory 
and ensuring that no otiier task exhausts n^oiy, then^ preventing the communicatbn subsystem fiom 
running. Conmiinucation flow control is implememed in the Device Connection Olject If the number of 
message buffers in the communications buffer pool reaches a predefined low level, all remote devices are 
inhibited from sending messages until the low buffer problem is resolved in the affected devk» preventing 
loss of messages. 

TCP-type communications are used for ai^lications using a streaming-t|pe protocol soch as file 
transfers and device flash downtoads. TCP-^e connections are temporary connections established for tiie 
duration of the applications needs and teiminated once the application has completed a commnnications task. 
For reasons of interoperability, compatibility, and availability, a TCP/IP protocol stack is employed. The 
TCP/IP stack supplies a coimection-oriented, byte stream protocd (TCP) and a connectionless, message 
oriented protocol (UDP). The device connection supports request/response messages, unsolicited data, and 
event and alarm data betwem devices. The communication system maintains the device connection through 
one of two available commnnications links in the event of a smgle oommuinicaticms fiihire, typically a c^le 

&nlt Detection of a fimh and switch to an ahernate communications path traiispires in a ^ort 
time s|ian which is less than one second. 

The operations hieiardiy is defined for a particular set of users, ^)ecifical]y operators and 
maintenance engineers, generally for die purpose of accessing dispkys, reports, and otiier informational 
items. A user interacts with tiie operations hierarchy on the basis of a site instance. User Granp itefinifim, a 
plam area instancy equipmem modute instances, control inodule instance^ 
instances. 
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The physical plant lueiarchy is defined for a paiticular set of users, q)ecificaUy maintenance 
enginecfs and tcchradans, typicaHy Jbr ihe purpose of determining physical relationships among objects and 
navigating maintenance infonnation about plant instnmients and equipment. A user interacts with the 
physical plant hieraidijr <m the basis of a site instance, a maintenance area instance, a plant area instaiux, 
n)om iiistances, cabinet instances^ node/device instances and display in 

The system objects that arc implemented in the multiple hierarchical systems are arranged into a 
itoality of subsystems inchiding control, piocess I/O, control system hardware, redundancy management, 
event/alarm managemem, hisi0ty services, proceK grapWcs. dia^ 

man^gmem organization and fiddmanagemem system (FMS) subsystem The control subsj^em includes 
routines fcMroonfiguriiw, installing and eioecuting control inod^ ThcjHocessI/O 
subsystem is a uniform interface to devices inchiding HART, Fieldbns, conventional I/O and other 
iiqjut/oulput systems. The control system hardware subsystem defines a control system topology, devices 
within the topology and c^bilitics and fimctions of the devices. The control system hardware subsystem 
also inchulcs objects and data structures for accessing device level information indicative of status and 
diagnostics. 

The redundancy management subsystem establishes a redundant context between primary and 
secondary control applications and manages switching in context bctw^n the primary and sccondaiy control 
applications. The redundancy management subsystem also maintains and monitors redundant context 
diagnostic information indudtng state infonnation and data latency information. Network redundancy is 
acconq>lished usiiig two separate Ethernet comnmnications links or networks. The primaiy communication 
link is the preferred communications path. Thesecondaiylinkisonly used if the primaiy has failed. 
Communications svidtchovers are performed on a per device basis. For example, if device A is 
communicating with devices B and C and the primary link to device C fails, device A continues to 
communicate with device B on the primary link but switches to the secondary link to communicate with 
device C. Each Etiiemet link is a separate, dedicated network having a dedicated set of IP addresses and a 
subnet mask. 

The device connection object manages redundant communications includmg controlling when to 
switch to the secondary link and when to switch bade to the primaiy link. Each device in the process control 
system trades the communication status of aU current links to remote devices by periodically sending link test 
messages when no other communications is occurring, to check the status of the communications links to 
eadidevice. Redundancy switdiovers are performed on a device connection basis. 

The event/alarm roanag;ement subsystem configures, monitors, and siqiplies notification of 
significant system states, acknowledgments and priority calculations. The history services subsystem stores 
and retrieves process and event mformation. The process gr^hics subsystem sillies user-defined views for 
display and operate imerfadng onto the defined system architecture The diagnostics presentatira 
subsystem funiishes displaiys of diagnostic information, typically at tiie request of a user. The user 
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envmuimait subsystem siqiplies a user intedace, allowiiig a user to enter commands to conuol operation of 
the process control emrironnient 100 shown in FIGURE IC. The managemem organization subsystem sets 
an oigaiiizationalstriicliiTeQfthe process control enraonmeht site, area, 

pnmithnes, access to user lihiaries, and location^ The FMS supplies user 

intetfeoes, views, and organization stiucturo for the conQguratiott, installation and monitoring of HART and 
Fiddbus devices. 

A Fididbus device in^lements localized control of a process within the process, i n contrast to a 
iCTlgerHiscd and more conventional approadi of controlling device junctions firnn « main nr centraiiyf>H 
^gital control system. A Fiddbus device achieves localized control by including smalU localized controUei/ 
imihi^dbcm 110 which arodoselyassodatedvra^ Thesmall, 
localized controllers of a Fieldbus implemoit standardized control fimctions or control Mocks which operate 

on the fidd devices within the Fiddbus device and which also operate on other smart fi^ 
connected to the Fieldbus ^mccl 

Thus, the process cantrol environment 100 implements smart field device standards, sndi as the 
Fieldbus HI standard, Profflms standard, CAN standard and other bus4iased aroMtectoro stands 
commnnications and control among device^ particulaity Fiddbus devices, are perfonned so that Fiddbus- 
type control operations aro transparent to a user. 

The process control environment 100 allows attachment to a substantially unlimited number and 
type of fidd devices induding smart devices, such as I^eldbus and HART devices, and conventional non- 
smart devices. Control and communication operations ofthe various numbos and types of devi^ 
advantageously performed sinniltaneonsty and in paralleL 

The process contrd environnicnt 100 implements and executes a standard set of function blodcs or 
contrd fimctions defined by a standard Fiddbus protocol, such as the Fiddbus H 1 standard, so that smart- 
type coiUrd is achieved with ii^)ect to non-smart*4ype deWce^ ^ 

convoitiona] device 136. In addition, the process control orvironment 100 enables Smart devices to 
in^lemem the standani set ofiunction blocks and control fimctions. Advanlageoosly, the {Hocess control 
enviroimiem 100 inq)lements an ovcraU strategy as ifaU connected devices are Sinartdev^ This 
inqdonentation is achieved, in part, by the usage of a function block as a fundamental building blodc for 
control fractures. These function blocks are defined to create control stnictnres for all ty^ 
Usage of fimction blocks as fondaraental building Modes is described in FIGURES 6. 7, 8 and 9. 

The process control environment 100 implements an overall, user-devdoped control strategy 
through the definition of function blods and control modules by downloading or installing specific portions 
of the control strategy into smart devices and non-smart devices. Thereafter, the smart devices automaticaQy 
peifonn the downloaded portions of the ov^all strata independently of odKr control system operations. 
For example, the portions of the cantrol strategy downbaded or installed into the devices operate 
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iiuiq)ea(femly of and in paiaUd iwth the contiol qjcrations of the controller/ mult^lexers 110 and the 
wmksiatioiis. vmt otfier control operati<»i$ manage the smart devices and implement other pottions of the 
oontioi strategy. In eflfect, the process contidenviiimmcnt 100 imjdements a 
contioUer^ mnltqdexers 110 within the smait devices. 

An example of a block diagram defining a function blodc of the functions 522 shown in HGURE 5 
is ilhistrated in FIGURE 6. SpecilicaUy. FIGURE 6 depicts an "elemental* function block definition 600 
whidi IS defined to oonlain only primitive objects. The elemental function block definition 600 defines a sum 
fimction and indudes a piinutivc 610, a fiisl ininit attt^ 
the primitive 610, and a second input attribute 622 1^ 

610. The primitive 610 produces a result that is sapplied as an oatpat attribute 630. In dus example, the 
demental fimction blodc d^nition 600 is a block definition that is cmted 

A second exam^Ae of a blodc diagram defining a fimcdon block of the functions 522 shown in 
FIGURE 5 is illustrated in FIGURE 7. Spedfically, FIGURE 7 depicts a "conqwritc" function blodc 
definition 700 whidi Is defined to contain one or more demeatal function Uodcs 600 and, opticmally, one or 
more primitive objects. The oonyiosite function blodc definition 700 defines a composite sum fimction and 
inchidcs a first SUM demcntal function block 710 and a second SUM demeittal function block 712, each of 
utoch is tiic same as the SUM demoital fimction bh)ck 600 iUustiated in FIGURE 6. The composite 
fimction block 700 has a first input attribute 720 and a second ifqnrt attribute 722 which are respective fiist 
and second parameters 724 and 726 applied to tiie first SUM elemental fimction block 710. The first 
demoital fimction blodc 710 produces a lesidt that is applied to tiic second SUM demcntal fimction block 
712 as a fiist parameter 730. The composite fimction block 700 has a third input attribute 728 tiiat is a 
seccmd parameter 732 applied to tiie second SUM demental fimction block 712. The second SUM demental 
fimction block 7U produces aiesulttiiat is suppUed as an output attribute 734. In this exan^}^ 
oonqsosite function block definition 700 is a block definition thai is created and named SUM3. 

An example of a block diagram defining a control module of the control modules 440 shown in 
nGURE 4 is illustrated in FIGURE 8. Spcdficafly, FIGURE 8 depicts a control module definition 800 
whidi is defined and contains various input attributes 810, demental function blodcs 820, a first S UM3 
composite fimction block 830 and a second SUM3 composite fimction blo<3c83Z The exenqdaiy control 
module 440 includes five input attributes 810 \^ch are connected to five respective demental fimction 
blodcs 820, three of which are parameters ^tted to the first SUM3 composite fimction blodc 830. The first 
SUM3 composite fimction blodc 830 produces a result that is supplied as a parameter to the second SUM3 
comporite fimction block 832 in combination wiUi parameters supphed Igr tiie remau^ 
fimction blodcs 820. The second SUM3 composite fimction blodc 832 produces a result tiiat is si^U^ 
output attribute 840. In dds exan^le, tiie control module 800 is a control module definitimi tiiat is created 
and named CMl. 
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Exaiiq)les of block diagrams defimng a module instance of the module instances 544 ^own in 
nCURE 5, specifically a control module instance, are shown in oio^ lo^l^,^ 9]0 

and 920 are created in aocoidanoe with the CM 1 control module definition so that each control modnle 
instance 910 and 920 inchides five hqnit attributes 91 2 and 922, respectively, that conespond to the five 
iiQRit attributes 810 diown in FIGURE 8. Each control n^idule instance 910 and 920 also indodes one 
on^ attribute 9 1 4 and 924, respectively, that cbnespond to the output attribnte 840 shown in FIGURE 8. 
Inthis examjde; the control module instances 910 and 920 are controi morfple instances •hat mi gyaffil and 
tagged CALCl and CALC2, lespectiv^. 

Using a defini t i on editor, a system user creates and names definitions; sudi as the SUM elemental 
fimdian bkx^ definitifm, the SUAf3 composite fimction block definition and the CMl omtrol module 
definition. Tlien, usii« a niodole editor, the s^rstem nsa* creates and tags inst^^ 
CALC2 control modide instances. 

Reforiiig to FIGURE 1 0, a flow chart shows an exan^le of control module execution at run^time. 
A nm-time program inchides a scheduler routine. Sdieduler routines are well-known in the computing arts. 
The scheduler routine requests execution 101 0 of a conqiosite control module, for example the campoaie 
control module 440 with tag CMl diown m FIGURE 8. The CMl con^wsite control module 440 initiates 
transfer 1012 of the input attributes 820, causing any associated links, or attribute associaticms, to transfer 
1014. A database definition typically refers to "associations" while a runtime definition relates to ^'links'*. In 
stqw 1016 through 1056 the CMl composite control module 440 requests each elemental function block 820. 
first SUM3 composite fimction block 830 and second SUM3 composite block 832 to execute in turn. 

Specificalfy, in step 1016 the CM! composite control module 440 requests each elemental fimction 
blodc 820 to execute. The elemental fimction blocks 820 initiate transfer 1018 of input attributes, for 
example first input attribute 612 shown in FIGURE 6. The input attributes of the elemental fimction blocks 
820 request 1020 loading of values fiom the links transferred in step 1014. The links copy 1022 vahies from 
souree attributes to destination attributes. The elemental fimction blocks 820 execute block algorithms 1024. 
Upon Gonqiletion of block algoritimi execution, the elemental fimction blocks 820 initiate transfer of ou^ut 
attiibates 1026, for example output attribute 630 shown in FIGURE 6. 

In step 1028 tiie CMl composite control module 440 requests first SUM3 coniposite fimction Mock 
830 to execute. First SUM3 cony)osite fimction block 830 initiates transfer 1030 of input attributes, for 
example inpat attributes 722. 724 and 726 shown in FIGURE 7. from the elemaital fimction blocks 820. In 
step 1032, fird SUM3 conqxxsite fimction block 830 requests mtenial fimction blocks, for example, the fiist 
SUM elemental fimction block 710 and the second SUM elemental fimction block 712 shown in FIGURE 7, 
to execute in turn. First SUM demental fimction block 710 reads input attributes, executes a block algorithm 
and sets an ou^ attribute in step 1 034. Second SUM elemental fimction blodc 712 reads Input attributes, 
executes a block algoritimi and sets an ou^nit attribute in stqs 1 036. First S UM3 composite fimction blodc 
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830 initiates transfer of outpmatmTmies in stq)103S, The output attribute of fiist S1JM3 conqHxate 
function block 830 requests an associated link to copy the vahie from the onqrat attribute in stq) 1040. 

In step 1042 the CMl comporite contiol module 440 lequests second SUM3 composite lunctioa 
block 832 to execute. Second SUM3 composite Junction block 832 initiates transfer 1044 of ii^ attributes 
from the links connected to the first SUM3oon¥OSitcfunctiOT In5tqil04«, 
second SUMJ con^wsite function block 832 requests internal function blocks, for ezanqde, the fiist SUM 
elemental function block 710 and the second SUM elemental function blodc 712 shovm in FIGURE 7. to 
execute in turn. First SUM elemental function block 710 reads input attrilmtes, executes a blodc algorithm 
and sets an oo^ attribute in step 1048. SeoMd SUM dcmMiial function blodc 712 reads iiq)ut attributes, 
executes a blodc algmthm and sets an ouQwt attribute in step 1050. Second SUM3 composite function block 
832 initiates transfer of output attributes in stq» 1052. The aaXptA attribute of second SUM3 campodti 
function block 832 requests an assodated link to copy the value from the output attribute in stq> 1054. 

In stq) 1056 the CMl composite control module 440 initiates transfer of output attributes and ou^ut 
attribute 840 requests a link from second SUM3 conqmate function block 832 to copy the vahic of the second 
SUM3compositefunctionblodc832ou^intattribntes. In some en*odimcms, output function blodcs push 
output lalues to a user-configured PIO blodc attribute (not shown). Thus, PIO attributes are filled" by 
fimction blodcs while ou^t function blodcs push outvalues to PIO Block attributes. Similarlsr, iiqmt 
function blodcs pull iiq»ut attribute values from PIO Block attributes. 

A user defines a module control strategy by sped^ng function blocks that 
and determine the control strategy. The user modifies or ddmgs a module control strategy by adding, 
modifying and ddeting fimction Wocks, omfiguring parameters assodated with the fimction blocks and 
creating a view to new attributes. 

By defining fimction blocks and control modules, a user^ned control strategy, application 
pfogram or diagnostic program is iq>resented as a set of layers of interconnected control 6t)jects identified as 
moAilcs. A layer oftheconlrol strategy indndes a set ofmodules which arc interoonnecledi^ 
specified manner. A module typical^ indudes an algorithm Ibr peifi>nning a specific fimction and display 
con^oncnts which are used to display information to a user. A module is optionally rq>resented to inciude a 
set of input and output connections for connecting to other modules. A module may be considered to be a 
liladc box" which performs a specified fimction and is connected to other modules via specified input and 
output connections. 

Referring to HGURE 1 1 , a display screen serves as a flow chart which shows an examfde of a 
module or apphcation program LOOPSIM 1060 at a highest layer of a conuolstru^ The iUustrated layer 
of the LOOPSIM 1060 application program indudes an input attribute (AIM) module 1062 called All, a 
deadtime module 1064, a prc^rtional, integral, differential (PID) control module 1066, an ou4)ut attribute 
(AOUT) module 1068 and a sumilate module 1070. Each of the iUustrative modules inchides named input 
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connections and outpmconnecaoiiswliic^aiecQiin^^ The set of modules, 

the iaptxx connections and the output connections of the set of module^ and the inten^rniections between 
modules define the operation of the LOOPSIM 1060 application. 

At a lowest level, a module is a set of interconnected function blocks. At higher levels, a module is 
a set of interconnected submodules which, in turn, may inchide a further set of submodules. For example^ the 
PID control module 1066 is typically a set of interconnected submodules which perform the different 
functions included in a PID functionality. The input and ou^ connections of the PID module 1066 are an 
input connection and an ou^ connection of one or mo;re of the submoddes witlun a ne^ 
PID module 1066. The submodules in the Pm module 1066 optionally mchideotiierinpma^ 
connections sufficient to define the intercomiections between the submodules. 

An application, a module or a sobmodule, at any module level, is optionally modiiicd by a user to 
perform a slightly different function or to poform die same function in a different manner. Thus, a user 
optionally modifies the n«>dule,therelormodi^g the coritrol structure,]^ Spedficaliy, a 

USCT optionally adds inpm and ouQmt connections to modules and extends the input and oatpvt cmmecUons of 
a module to a higher levd module 50 customize modules for various application^ Por example, a user 
optionally adds a new input connection or ou^ connection to the PID module 1066 to the ''edge" of the PID 
module 1 066 which makes the input connection and output connection ^pear as input and output 
coimections to the PID module 1066. 

The process control environment facilitates the definition and modification of the control structure 
by furnishing editing operations in a plurality of control languages including IEC*1 13 1 standard languages 
such as Field Blocks, Sequential Function Charts (SFC), Ladder Logic and Structured Text According^, 
different types of users, from different control backgrounds use the diffeiem languages to write diffoent 
modules for implementing the same or different applications. 

Control modules aie specified to have several advantageous characteristic^. Some control modules 
allow direct access to attributes. For exan^le, some attributes, called "heavy" attributes, support dircrt 
(maximum performance) communications. Direct communications are advantageously used for connectiiig 
function blodcs and Ccmtrol Modules, supporting event/alann detection, and high performance trending, for 
exanq)le. Some attributes are created automatically upon definition of a control module with a user having 
the option to promote ot force a parameter to be esqwsed as an attribute of a Control Module. OOier 
parameteis are made accessible thnmgih a module, sudi as a Control Module, an Equipment Module, a PIO 
Block, or a Device, which comains the parameter but direct conmnmications performance of the attributes 
does rim warrant the overhead incurred in applying this performance. These parameters are advantageously 
accessed to supply information relating to control system tunti^, debugging and maintenance. In some 
embodiments, these parameters arc accessed by a general purpose parameter browser plications, idiich use 
services provided by Ugged containers to reveal attributes, invdceable seivioes, and subcomponents within 
the containen. 
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Refening to FIGUR£ 12, a block diagram iUustiates an objea-onented method for installing a 
process I/O attnlwle block into a PIO device throngh the operat^^ Ablodcof 
defined objects 1110 includes a die object 1112, a controUer device 1114, a controUer I/O subsystem 1116. a 
PIO intedace device 1118 and a PIG device 1 120. Prior to installation of the PIO device, the controUer VO 
sobsjfstem 1116 is previousty created. The PIO device 1120 is also previoosly created, dther by insl^ 
or downloading. The block of defined otgects 1110 directs a detail pointer 1122 to a list itf block definitions 
1124 to qiedfy a particolar ^ of oljecl to be created by a create po^ 

create block 1128. The block d^tions 1124 inchtdes a PIO input attribi^ (AIN) bkxic definition either 
as hardwired or by previous installation. Attnlmtesofthe specified otjcctaie set by a user through the 
operation of an editor 1 130. Prior to installation of the PIO device^ an inpnt attribute (ASH) bkx* 1132 does 
not exist. 

Prior to installing the AIN block 1 132, a user creates the PIO device 1 1 20 then sets up initial vahies 
for AIN block attributes using the editor 1130. The user also sets aperiod for view parameter acquisition. 
The AIN block 1132 is saved and then installed. 

Refening to FIGURE 13, a block diagram illustrates an dbject-^niented method for linking a 
Control Module mpm attribute to a process I/O attribute. Prior to linking ofthe control module input 
attribute to the PIO attribute, the PIO block AIN 1220 is previously installed and the control module 1210 is 
also instaUed, The user specifies that a PIOIN attribute 1212 ofthe control module 1210 is connected to an 
attribute input process variable PV 1214 and requests that a Knk be made. A link 1216 is made as the control 
module finds the PIOIN attribute and returns a concsponding attribute index, locates PIO AIN in a plant 
area, find the process variable PV attribute and retains a corresponding attribute index, instructs the run-time 
linker 1 2 16 to create a link with a source at the process variable (PV) 1 2 1 4 and a destination at the PIOIN 
attribute 1212, creates the link and connects the Imk 1216. At end of a download , links ate resolved by the 
linked objects. 

Kcfening to FIGURE 14, a block diagram shows an object-oriented method for linking a control 
module output attribute (AOUT) 1312 attifiyute to a PIO outpm attribute (PIOAOUT) 1320. A control 
module 1310 is previous^ instatted and the contr<d module output attribute (AOUD 1312 is installed within 
the coQtnA module 1310. The iiserqiecifies that the oontnd module ou^ attribute (AOUT) 1312 is 
connected to the a PIO ou^t attribute (PIOAOirn 1320. The link is made as the run-time implementation 
of the control module 13 10 is sent a message to form the connection, the control module 1310 finds the 
AOUT attribute, requests hxation ofthe PIOAOUT attribute 1320, creates a link 1322 and connects the 
AOUT attribute 1312 ami the PIOAOUT attribute 1320 to the link 1322. 

Referring to FIGURE 1 5, a block diagnun shows an olyject-oriented method for readir^g values of 
contained PIO attributes. A PIO Uodk 1410 is previous^ installed aid an ouipmattribme(AOU^^ 
previously installed withm the PIO bk>dcl410. A user, for exanqile an engmeer. requests a detailed view of 
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the Mock in whidiaU attribute vdnesaiediq)!^^ The detailed display Includes one or more sets of 
di^ gtaaps, also caUed view definitioas. assod^oed with the PIO block 1410. A proxy is previously 
eaahllshed fiir the PIO Block 1410. A user requests detail for the output attribute (AOUI) 1412. Attribute 
names and vahies forthe AOOTblock are presented by an appUcation program re<iiiestiiig aproxy diem 

routine to access a view, an ADOT proxy dficnt settii« a return view defimtlOT 
proxy olgect, and theapiakatkmpK^ 

named with gnuited privileges. Ttaapplicalioaprogimlbiniatsanddisphvsto Displaygroup 
parameters arc part ofanWJWoA definition and are. therefore, not configw* 
forattributes. Infonnation is advanlageoosty updated while a PIO blodc is not linked s^ 
and view gnnqs contntf updating of non-Bnked no attributes associated with a bUK*. 

The process contio] environment 100 shown in RGimE iC implements an pvetaU stnttegy as if all 
c»mnected devices are Fiddbus devices not only by liu! usage of a flmction bl^ 

block for control simctores. but also by implementing an iiqrat/output architecture that tre^ Fiddbns and 
nonRddbus devices in the same manner. The fundamental character of the inpnt/output architecture is 
based on instrument signal t^ (ISTs) that furnish uscr<onfigurable names for all I/O signals indudbig 
Fiddbus and nonFieldbns I/O signals. 

From the perspective of a user, an 1ST binds a user-defined name to a signal type, to a specific agnal 
in the 1/0 subsystem, to a signal path inchiding an attribute and to a set (rf signal property settings. 

lSTsarenotinstaUedlnthemannc»ofother^ystcmd>jects. Instead, signal inopcaties inherent to 
the 1ST tag are combined with I/O Port and I/O Device properties that are made availdtle when aaVOCaxd 
is installed. The combination of 1ST, I/O Port and VO Device properties furnish infonnation for creatmg a 
PIO function block in the nurtime system. The signal path from ISTs is indnded in the script that defines 
I/O Function Blocks during installation of a module. 

To commuakate duDughoot the process control ennronmeni 100. an I/O type Fonclian Bkidc uses 
25 an I/O reference d^tion. An 1ST satisfies the qiecification for an I/O leference. Omvemimia] I/O 

devices, such as MTL devices supplied by Measurement Technologies Limited of the United Kin^iran. have 
an 1ST for each channel Hart and Fiddbus VO devices may indude an 1ST for each distinct "I/O signaT on 
a Pwt or in a field Device. 1ST names have system-wide scqic and share the name ipace of Module?. 
Devioes, and Areas, hi la^qstem?, ISTs t«)icaltycoirEqiond to instrnmeM signal namw 
mstfunMntatmn drawii^gs.. In smaU qjslem^ formal instrumem drau^ 
1ST names are inferred. Typicdty, ISTs are autcmiaticaltygMKrated as cards are cOTfigmedba^ 
devkx Merardiy path represeniii« a controller node. W) snh^^ 

names are avoided. T^picaUy most ISTs are aeated automatically when a new I/O card is defined Fw 
muMplMagnal VO devices, an 1ST is automatically oealed for only a single >rimaiy signal". In addition 
to automatk 1ST creation, a user may dso create ISTs using an"Assign.„"memiavailahlefiomthe 
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Explorer hMe/IOsubsys^ait/Dcvice tree with a Po 
firom the Explorer 1ST tree. 

ISTs have a "sigDsa tjfpe" property to ensure compatilnAiqrbaweeii the I/O signal and the I/O 
FimciionBlock(s) that accesses the I/O signal Signal ^ is one of: AIN, AOUT. DIN, DOUT. PON, 
PCOUT. ISTs have a set of "signal-relatecT attribates specific to the ^gnal Q^pe (e.g. EUO and EUlOO for a 
AIN.MOMEm'ARYorlw^TCHEDfbraTOUT.etc.). All signal sources with the same signal type have 
the same set of **signal attribiites". All other properties of the I/O subsystem obfects are hdd in card, port, or 
device attrilmtes. 

Fully configured ISTs have a folly qual ified path to a corresponding signal in the I/O system, e. g. 
-CONl/IOl/S0iyC01/FIELD_VAL'*. An 1ST may be created without a defined path defined so that module 
configuration may be completed before UO structure details are fully defined! Modules with I/O Function 
Blocks usmg ISTs with no defined path may be configured and installed but the run-time system must deal 
^pn^ttiatdywi&niissingl/OpathsitfmissinglSTsQnVOF^ A signal source has no more 

thanonelST. Attempts to configure more than one 1ST with the same path are rejected. 

A user may delete an 1ST, ther^ deleting associated signal properties and possibty leaving some 
unresolvable 1ST references in I/OFtancdon Blocks. A deleted 1ST docs not afiect caid/port/device properties 
with a nonnal display of the 1ST on fiie Poh/Device in the E9q>lorer tree indicating no associated 1ST, 

I/O-interfiacc Function Blocks have at least one IST-Refercnce property. An IST-Reference property 
is either left blank to indicate that the function block does not connect to a 1ST, or is designated with a vaHd 
1ST name. An IST-Reference property in an I/O Function Block is compatible with exactly one 1ST signal 
type. For example, the IST-Rdisrence in the AI Function BloA has an 1ST with a signal type **AIhr only. 
Several I/O Function Blodcs are compatible with the same 1ST signal type. 

For compatibihty with Fieldbus I/O Function Block definitions, Fieldbus I/O Function Blocks have 
attributes such as XD_SCALE, OUT^SCALE which overlap with some of the signal properties in ISTs. 
When a valid IST-Reference is made, the configured vahies of these overlapped Function Block attiibmes are 
ignored in the Run-time system and the corresponding properties from the I^^ Anengineer 
configuxing Fieldbus I/O Function Bladss uses an indication <tf ignored attributes when a 1ST reference is in 
place. Such an indication is typically presented on a display as grayed om and non-edit 
oqried from the 1ST. The I/O Function Block holds a private setting for the ignored atiiilmtes^rtBch are 
typically downloaded and promptly overriddea If the IST-Reference is removed, the setting for these 
attributes retains utiHity. 

I/O Cards, Ports and Devices are incorporated into a oonfiguiation by a user ope^ 
intet&ce, either the Es^lorei™ or the Module Definition Editor. The diannds on conventional I/O cards are 
caUed "ports" and treated as an I/O Port so that special case terminology for convotiional I/O is avoided. 
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The user interface also allows a usor to delete I/O Cards, Ports or Devices. Multiple I/O Card ^pes are 
siqypoited including for example, S-dian Mm AI, S-chan MTL AO, 8<han MTLDI, Z^hm MTL DO. 4- 
durn MTL Thermocouple^TD, 8-chan HART iiqiut, 8-chanHART output, and 4-chanSolcnoid. Some I/O 
Cant types have a combination ofl/OI^xtQfpes on the sarne I/O Ca^ Deletion of an I/O Card ddetes all 
subordinate Ports. Ddction of an I/O Port delete idlsidMxdinate Devices Dektitmof I/OPortsorl/O 
Devices does not ddete related instrument signal tags (ISTsX but the path of the 1ST path to the associated 
I/O signal no longer is (^>efable. If anothei I/O Port or UO Device is gpeated which hag thg gam p^^K, thf 
1ST automatically rebinds to the I/O Port or I/O Device, so loiig as the signal type is compatible. 

A usor can initiate the InstaU of an I/O subsystem, which instdls or rei^^ 
in the Subsystem. The user can initiate the InstaDofasin^ I/O Card, wluch installs thecal 
all properties for subordinate I/O Ports and I/O Devices. 

The Explorer'"^ and the Module Definition Editor configure the I/O subsystem by accessing current 
signal vahies, status, and selected prqierties that are directly address 
The user di^lays a graphic indicative of the ctttrem status of cards, ports, devices, and signd 
status Iqr accessing the respective cards, ports, deWccs and dgnal values aiid status ua 
attnlmte path addresdng (for example, "CONl/IOl/COI/POl/FIELD^VAL'O. 

I/O subsystem attributes are coihmimicated using the physical device path (for example, 
CONl/IOl/C0iyiM>l/D01/in£LD_VAL) for addressing in comnumic^ Communication 
of I/O siibsystm attributes is advantageously used to transmit attributes from a oontroller/muitiplexer 110 to 
a workstation 102, 104, 106 as shown in FIGURE IC for displ^ and from a first to a second 
oontrollei/maltiplexer 110 for virtual I/O handling. 

Referring to FIGURE 16, a block diagram illustiates an organization of information for an 
instrumem signal tag QST). An sy&ssa 1ST tal>le 1510 contains information relating to an 1ST including 
path infonnafion and pdntos to a system tjbject A first pointer 1512 dedgnates a signal type viMch points 
to an attribute signal table 1520. A second pointer 1514 designates an entiy in the attribute signal table 
1520. 

Accessing of infonnatimi using device hierarchy attribute addressing advantageously allows system 
diagnostic displays to be deagned and buih system integration diedco^ 

oon^te. Device hierarchy attribute addressing also suppoits direct addressing of I/O agnals from Modules, 
bypassing the use of I/O fimction blocks and avoiding I/O function block behavior. I/O Card, I/O Port and 
I/O Device identifiers are genially defined automatically according to slot position information and the like. 

Referring to FIGURE 17, a flow chart illustrates a method for bootstrap loading a control system 
thfOttghont a netwoik in the process control emironment 100, including the operations of assigning the 
cantroUei/ muhqiiexeis llOtoasetoflP Addresses, a node name and other startup informatioa that is not 
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stored in flash ROMs of a controller/ multiplexer 110. A process M?00 for assigning internet protocol (IP) 

Addresses to a ControUer iq>on its initial booti^) indudes the step of associating a 

seiver, a Windows NT^ woikstation, with a controller/ mnltipiexcr name 1610. The MAC address alone 

designates the oontrollei/ multiplexer identity. In step 1612, the name of the controller/multiplexer is 

assigned an aiintraiy device ID, and an ACN link number and a PCN network number that are d^ermined by 

the c^ie attached to the Gontioller/ multiplexer. In step 1614, an IP address ofa device is cateolaied from 

the device ID, the ACN ]mknnnd)er and the IHZNnetWDricnmito^ In step 1616, a UDP datagram, which 

des ignate s default primary and secondary IP addresses that are ireserved for booting nodes and indodes the 

controller/ mnltipiexer MAC address in the UDP nser data, is broadcast to a spcdzl UDP reserved boot pmt 

using the de&ult primary IP address for the source address on the primary intcrfecc. In stqj 1 618. the boot 

server matches the MAC address with the a!»igned name and IP addresses, and broadcasts the aggigned name 

and IP addresses with an echo of the MAC address to the UDP boot port By broadcasting, 

doing aiqr routing or ARP static entry manipulatitm is avoided. Instep 1620, the controller/ mnitq>lexer 

receives the datagram, chedcs the MAC address, and if the MAC address inatches, sets the m 

saves the node name and device ID. Ifthe datagram is not received, the procedure is rqteated using the 

secondary imer£ace through the operation of branch step 1622. In st^ 1624. the controliet/ multiplexer, 

nsing the new address, sends a message to the boot server sayir^ iiidicating that the controll er/ multiplexer is 

operational. 

In step 1626, a user enters a Device Name, Device MAC Address, ACN Link Number and PCN 
Network Nurnber. The device ID can be amoniatically assigned by corifignrati<m software^ The 
communications subsystem calculates the devices three IP addresses firom the configured ACN Link number, 
PCN Network Number and the assigned device ID. In step 1628, controller/ multiplexer or I/O card software 
is flash downloaded over the ACN network by passing messages and S-Record files between devices on the 
ACN. 

Referring to FIGURE 18, an object oortununication diagram shows a method for creating a device 
cormection for the active, originating side of a connectioa An application program in either a workstation or 
a controUer/ multiplexer requests access to an attribute which is contained in another device. A UDP 
communications connection to the other device is established by the oomnnmication services so that the 
attribute can be accessed. Creation of a device ccmnection spans two sqiarate application prograins. The 
application prpgiam which initiates the connection by requesting data located in another device and the 
Remote Object Co mim m ic a f ions (ROQ Sendees i^lication program that actual^ sends the messages to the 
otherdevice. ffnocomiection exists when the ROC Services pnicess is ready to send a mess^ to a device^ 
the ROC services create a cmmection to that device. 

Prior to creatii^ the device connection, a device to be connected has a valid Device Table contaming 
the source device, is operating and incfaides an olject RtDeWceConnection w 
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device oamiecticniiKHt Alter the device connection is cieated» acorns 

devices and an RlDeviceCoBBection instance is created in the active device to lumdle the omnectio^ 

In step 1710, an application program sends a message getContainer to object RtSke wbich letnms 
the otrjea ID of the module found or created. faistq> 1712»olgectRtSite sends a Locate message to object 
S RtPlantAreawluch locates the module and letmn its object ID. In step 1714, objeal^ 

GelDevice message to object RtDevice whidi letams the dbject ID of the device gnntaiiiing the module. In 
stq> 1716, assuming that a pros^ ibr the ronote device does not exist, object RtDevice sends a Craite 
message to object RtDcviceProxy. In step 1718, object RtDeviceProxy creates an instance of dbject 
RtDeviceProxy using template RtNew. In stq> 1720, object RtDeviceProxy asks deject 

10 RtDcviceConnection to GetDeviceConnectionlndex which letums the index of the device name in the 
device connection table managed by object RfDeviceConnection. In stqi 1722, object RtDeviceProxy 
registers the pointer to the RtDeviceProxy instance for the connected device by sending a RcgisCcrPointcr 
message to the object RtR^jjstry and returns the device proxy Object ID to object RtDevice. In step 1724, 
object lUPIantArea sends a Create message to object RtModnleProxy Client to create a pt03cy dietU for the 

15 remote module. In step 1726, object RtModulcProxyClient sends a Create ni«efaig« to olgect 

RtModuleProxyServer to create a proxy server for the module in the remote device. In st^ 1728, object 
RtModuleProxyServer builds a create proxy server message and asks object RtRocReqRespScrvice to 
SendReqaest to the remote device. In step 1730, object RtRocReqRespService Appends the message to the 
Ontboond Message Quene for the ROC Communications Services process to send to the remote device. In 

20 5tq> 1732, object RtRocReqRc^Service in the ROC Comm Services process issues a RemoveFSrst 

command to the Ontbonnd Message Qncne and gets the create proxy smci message. In stq> 1734, the 
RtRocReqResn^rvice sends the message by issuing a sendMsg command to the aRtDeviccProxy instance 
for the destination device. In step 1736, the aRtDeviceProxy instance issues a GetDeviceCoiiiiectlon 
command to RtDcviceConnection to get the Object ID for the RtDcviceConnection instance for the 

25 destination device. Assuming that a device connection does joot already exist, in step 1738, object 

RtDeviceCoimection performs a createDeviceConnection. In step 1 740, object RtDeviceConnection 
creates an instance of RtDeviceCoimection using template RtNew. In step 1742, object 
RtDcviceConnection registers the pointer to the RtDeviceConnection instance by sendiqg a 
RegislerPolnter message to the object RtReglstry and returns the device connection Otgect ID to olgect 

30 ' RtDeviceConnection. In step 1744, object RtDeviceConiiection sends a startActiveOmnection message to 
the aRtDeviceConnection instance. The aRtPeviccConnection instance performs the necessary stqis to 
establish the connection to the other device. In step 1746, the RtDeviceProxy instance issues a sendMsg to 
the aRtDeviceCoimection instance to send the create server message to the remote device. In stq> 1748, the 
aRtDeviceConnection instance sends the message to the remote device over the newly created coimectiorL 

3 5 Refeniiig to FIGURE 19, an object communicaticm diagram siiows a method for cresdir^ a device 

coimection for the pasfflvey listening side of a connectjon. A request to egtahli leh a Hgyirft ^nnnf^ffn 
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received from another woricstation or controlki/ multiplexer. The communications services establishes a 
UDP commonicatimis connection with the requesting device. 

Previous to creation of the connection, a device to be connected to is operating and contains an 
object aRd>evlceCQnnecdon which is ready to establish a connectioa Object RtDevice CoDuectioB exists in 
the dewcc and is listening for iiqrat messages in the form ofa sync request After the connection is cicalcd, a 
connection is established between the two devices and an WDcviceCo^ instance is created in the 
passive devioB to handle the comiectioa 

In step ISIO, object RtDeviceComiectioa reoehfes a sync request message from a remote device, hi 
step 1812, dgect RtDeviceConnection sends a Create message to dbjed lUDcviceConnection to create a 
connection to the requesting device. Assuming that a device connection does not aheady exist, dgect 
RtDeviceConnection performs a createDeviceConncctton in $tq) 1814. In step 1816, object 
RtDeviceCoiincctiai creates an instance of RtDevkeConnection using template RtNew. In step 1818, 
dgect RiDeviceiConncction registers the points to the RtDevkeConnection instance by sending a 
RegisterPouiter message to the RtRi^ry and retains the device connection object ID to object 
RtDevkeConnection. In stq> 1820, object RtDeviceConnection sends a &eate message to ol^ect 
RtDeviceProxy to create a device proxy for the requesting device. In step 1822, object RtDeviccProxy 
creates an instance of RtDeviceProxy using template RtNcw. In step 1824, object RtDeviceProxy sends a 
GetDeviceConnectionlndex message to the object RtDeviceConnecUon to have the index of the device in 
the device connection table managed by RtDevkeConnection for later use. In step 1826, object 
RtDeviceProxy registers the pointer to the RtDeviceProxy instance by sending a RegisterPointer message 
to the RtRegistry and returns the device pi03^ olgea ID to RtDeviceConnection. In step 1828, dbjed 
RtDevkeConnection passes the sync request message to the aRtDeviceConnection instance for processing 
via the bandklnboandMessage method. In step 1830, object aRtDeviceConnection sends a sync response 
message bade to the remote device to indicate successful ccmiplt^on of the Device Connection creation. 

Referring to FIGURE 20, an object communication diagram illustrates a method for sending 
request/ reqxmse messages between devices. The remote object communications (ROO service in one device 
sends a request message to the ROC sendee in another device. The request message is processed and a 
response message is sent back to tiie originating device. 

Prior to sending nusssagcs, a UDP device connection is established between^ Followingthe 
sending of request/ response messages between devices, a response messa^ from a remote device has been 
received and is ready for piDoessing by ROC services. 

In step 1910, a read attribute request is issued by an application program to an aRtDevkePro^ 
instance associated wiOi a remote device. In step 1912, the aRtDevkeProiy instance builds a request 
message to be sem to the remote device to read the attn^me value and asks to 
send the message using the SendReqnest method. In step 1914, object RtRocReqRespService sends the 
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message to the instance of RtDeviceConnection associated ivith the connection to the lemote device nsiQg 
the send.BUg method. In stq> 1916, the instance of RtDeviceConncction then transmha the message to the 
remote device over the device conncctioa In step 1918, the instance of RtDeviceConnection in the lemote 
device receives the message and requests the RtRocRonter class to route the message to the correct inbound 
message service. In step 1920, object RtRocRonter deteimines that the message is a request/response 
message and xe^iests object RIRocReqRespSerme to Pro Afltf the message is 

imwessed l3y the ROC services and the message oonsimier a reqwnse me^ 

RfltocRgstRcgpScnicg soids the response message to the mgingting device ming the jSwiiiy pg^ffngf 
method. In step 1924, the outbound message queue processing of RlRocRcqRcspSendlce sends the response 
message to the instance of RtDeWceConriection associated ivith the comiecti 

send^msg method. In step 1926, the instance of RtDevice€<mnection then transmits the response message 
back to the original device, in step 1928, the instance of RtDeviceConnection in the original device receives 
the message and requests the RtRocRonter class to nrate the message to the correct inbound message 
service. In stq> 1930, object RtRocRonter determines that the message is a request/response message and 
requests RtRocReqRespService to jProoessMnboundRcqResp. 

Referring to FIGURE 21 an object communication diagram illustrates a method dowidoading a 
network configuration. A user, foUovidng completion of the device configuration for a system, initiates a 
download to a controUei/ mnltipIexBr. A device table configuration script is built by the configuration 
q^ication. Using communications seraces , the configuration ^plication establishes a device connection 
with the oontrolltf / multq)lexer to receive the download and sends a download script to the controller device. 
The controller/ nniltiplexer receives the download script messages and processes the device table. In step 
2010, a configuration download application program builds remote object communications (ROQ script 
download messages containing the device table download script. In step 2012, the Download plication 
issues a GetDevice message to RtDevice to get the Object ID for the RtDeviceProxy for the remote device. 
In step 2014. the RtDeviceFroxy docs not yet exist so a Create message is sent to RtDeviceProxyC to create 
the necessary device proxy object In step 2016, RtDeviccPnoyC sends a GctDeviccConnlndex message to 
RdleviceConnecticni to get the iikdexofthe device oonnecticm for the remote device in the device 
connection table. In step 2018^ the device connection does not yet exist so aRtDeviceConnectioii dgect is 
created to manage the connection to the remote device. A lookup is peifoimed in the database to find the 
remote device entry. The device communications data (for example, ID and IP Addresses) is retrieved from 
the database and a new entry is added to the configuration devices connection tahle. This connection is 
marked permanent in the connection table since the device initiated the connectiort In step 2020, a 
startActiveConnection message is sent to the aRtDeviceConnecti<m objea to establish a connection to the 
remote device. In step 2022, the aRtDeviceConnecticni sends an RtSyncMessage to the remote device. In 
step 2024, the remote device receives the RtSyncMessage and attenqMs to find an entry in the device 
connection table for the sendiiig device. In step 2026» no entiy is found so a new 

connection table for the sending device and aRtDeviceOmnection dtjea is created to handle the connection 
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in the receiving device. In s(q> 2028, a RtSyncRcplyMessagc is created and sent back to the sending device 
containing the device connection index from the device table. The device connection is now established and 
icady to send and receive messages. In stq) 2030, the RtDeviceProxyC sends a create RtDeviceProryS 
message to the remote device. In stq> 2032, the RtBeviceProxyS is created in the remote device. In step 
2034, the IHiwnloadAppUcation sends the download soipis to the remote device^ 
RtRocReqRespSeniccs using the SeadMsg calL In stG|> 203$. RtCommScrqitDownload receives the 
Device Table scfipt and ptDoesses eadi device table item and stores the data ^ 
hold configmadon data. ForcoiitrolleiyflmtiQilafeRthisiiiDoesangisn^ 
cArjects and add the objects to the device connection t^Ue^ aUowing the m^^ 
rather than scibseqaently. 

The digital control system program 115 inchides a diagnostic program and diqday routine for 
viewing diagnostic information rdating to a process in a coherent manner, whether the diagnostic 
information is derived fiom a Fieldbus device or a nonFieldbas device. The digital control system program 
115 advantageously incoiporates diagnostic information relating to all devices within the process control 
environment 100 and presents this information to a user in a uniform marmer using the diagnostic display 
routine so that the control strategy and the diagnostic information are presented to a user as if all control 
actions and diag n ostic infbnnation were performed or generated at a single location. 

Referring to FIGURE 22, a pictorial view of a ftont-of-screen display illustrates a flowchart of the 
operations of a diagnostic display routine 2200 including a communication diagnostics program 2210. A 
user gr^hically views the status and integrity of workstations, conUollers and network links within the 
process control environment 100 using easify*-recognized icons. The diagnostic display routine 2200 also 
generates summary status information for a device or network link segment The diagnostic display routine 
2200 displays detailed internal integrity information concerning devices connected to the network, including 
padc^ salt and received, the number of connections and the like. Some diagtmstic information is accessed 
via modem to inqilement remote diagnostics functionality. 

A workstation 102 or 104 and controller/ multq)lexer 110 function in combination to suppfy detailed 
diagnostic information about the status of the cornmunications subsystem in connected devices indw Hifig 
detailed integrity infmnation alnnn the status of the ACN communications links, device connectiQns, 
ethemet statistics, and oommonicatiQiis stack dbignosticinfoimatioa A diagnostic dieck of communication 
fimctionality is also supported. The comimmication diagnostics 2210 siqiport three levek of diagnostic 
information including basic diagnostics for the entire network, diagnostic informatbn for a single device and 
^agnostic information for a single device oormection. 

At the basic network dmgnostic level, the communication diagnostics 2210 gather information fiom 
all network devices and present the infcnrmation to a user. The communication diagnostics 2210 odlect 
information from remote oontrollerAnuhiplexers 110 on ii^wiatMi or as a background taA executing 
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periodkally. The oomimiiiication diagnostics 3210 sendnetwoik camnniiucslioiis status rpcpicsts to a 
diagnose poit of a paiticular device to determine intpgiity of the commimieatioiis path to that device. 

A lesponse to a netwoik oommuiitcatioiis status request contains communicatioDs integri^ 
infonnation inclu di ng device type infoimation initicative of whether the device is a cootroner or woiksution, 
and primary and secondary status summary information. The Connection Status Summary* which is set to 
*3ad" if an error exists on the link, is added as an attribute to a Communications Subsystem Module^ 
allowing a user to (fi^Iay these vahies on the opemtor inter&ce upon request 

The co nmmnicat i o a diagnostics 2210 request diagnostic infonnatioa fiom each device connected 
into the process control eoviromnent 100 so that tlw status of the commmiications liriks between the device 
and a remote device are displayed. 

Tlie commnnicatioiis diagnostics 2210 monitor and display diagnostic information fisr a single 
device to supply detailed dis^gnostic infonnation ^ut communications for a particular device, inchiding linV 
status information for device connections and the ethemet statistics for ethemet intecfaoes in the device. The 
c ommunic ations diagnostics 2210 request the device communications status using an appropriate diagnostic 
remote objea communications (ROC) message. The device communications status indudes infonnation such 
as a Device Table Index, a Device ID, a Device Connection State (Ready, Synching, ACK Pending, Closed), 
a Primary Device Address, a Secondary bevice Address, a Link Status and diagnostic information for a 
sin^ device oormection. 

Ethemet statistical infonnation is held in counters which start counting when the device is booted 
and are not reset until r^ioot of the device. The counts are implemented as attn7>utes to the Communications 
subsystem module as part of the module attributes and include ii^t error information including numbers 6[ 
total ir^ut errors, wpal CRC mots and input overrun enors. Output emr infonnation indudes nimibers of 
total output errors; output late collisions, output colHsions exceeding a preselected number, output overrun 
errors and oul|mt canier lost errors. Other counts include the numbers of packets received, padcets sent, 
bytes received, l^es sent, broadcast padcets received, broadcast packets sent, unknown protocol messages 
received, transmit deferrals, single collision transmits and multiple collision transmits. 

The oo mmnmc ations diagnostics 2210 also monitor and display detailed diagnostic information for 
a particular device connection in a particular device. When a useriequests device connection statistics, the 
communications diagnostics 2210 designate a destination device ID for a connection. Device connection 
statistics contain link status infonnation and statistical infonnation for the designated device cormection, 
including a Device Connection Sutc (Ready, Synching, ACK Pending, Closed), a Remote Primary Address 
(Primary ACN IP Address for the destination device), a Remote Secondaiy Address (Secondary ACN IP 
Address for this device or 0), a Primaiy Link Status (Gk)od/Bad), a Secondary Link Status ((jood/Bad). The 
statistics also indude counts ofmessages received on Prirnary Link, rnessages receive 
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messages seal on Piimaiy Link, messages sent on Secondaiy Link, Synchs Sait, Synchs Received, ACK 
Tline-OQts on Primaiy Link» and ACK Timenm 

The communications diagnostics 2210 suppoit checking of a communications path between two 
devices in a network. A first device sends a message, such as an evoking message, over a specified 
oommunication link to a remote device. The remote device echoes the message back to the sender. A 
sucoessfbl evtddng message and echo are indicative that the oonmnmications subsystem is iimctional in the 
xemote device. Tins interaction is different from a nonnal TCPTIP ping which ig han ^ } f4 irmpi^^ by an 
elhemet hardware driver. 

Refefring to FIGURE 23, an object communication diagram illustrates a method for one device to 
check whether another device exists on a netWDik. A diagnostic appHcation program which is either part of 
the process control environment or a stand-alone q>pIication monitors to determine whether a remote device 
exists on an ACN network and, if so. whether the remote device is capable of cinmin^inicafion^ The 
diagnostic application program sends a message to the remote device and expects to recdve themcss^ 
echoed from the iraiote device or a time-cut 

In stq> 2310, a diagnostic application program sends a Phig message to object RtQ)mmDiag 
requesting that a communication inquiry (ping) be performed to a specified device name or addcess. In st^ 
2312, object RtCommDiag creates a communications socket to.peiform the inquiiy. In step 2314, diject 
RtCommBiag creates an RtEchoMessage to send to the remote device. In sxep 231«, object RtCdnunDiag 
sends the RtEchoMessage to the specified device using RtCommSendTo and waits for the message to be 
echoed back from the remote device. In step 2318, object RtDeviceConnection in the remote device receives 
the RtEchoMessage and processes the message using the HandlcDiagnosticMessage method. In step 2320, 
object RtDeviceConncctioD immediately returns an RtEchoMessage with a diag code of echo response to 
object RtComniDiag in the source device using RtCommS^tToMessage. In step 2322, object 
RtCommUiag receives the echo response message and returns a successful status to the diagnostic 
apidicatioa Ifno response is recdved from the remote device, in step 2324, object RtO^^ 
feOed status to the diagnostic appHcation. In step 2326. object RtCommDiag closes the socket created to 
pofozm the inquiiy. 

Referring to FIGURE 24, an otject communication diagram illustrates a method for requesting 
device communications diagnoistics. A diagnostic appOcationprogiam requests; accesses and displ^ the 
status ofan device connections in a remote device. The diagnostic application progiam sends a request for 
the required diagnostic infonnation to the remote device and waits for a response. Onoetheiesponseis 
received, aD device connections and device status in the remote device are displayed to the user. This 
information may be communicated in multiple messages so that tiie diagnostic plication program makes 
multiple requests for diagnostic data. 
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In step 2410, a Diagnostic ^pUcatioii progiam sends a GetDeviceCommDiags request to object 
RtCommDiag to fequest communications diagnostics for the device connections in the remote device. In step 
2412, object RtCommDiag sends a GetDeviceConnectioiiIndex message to object RtDeviceConnection to 
request the device connection table index for the remote device. In step 2414, object RtCommDiag issues a 
Create to object RtRocMessage to create a message to be used to request diagnostic infoimation. In step 
24 1 6, object RtRocMcssage creates a new instance of aRtRocMessage to be used for the diagnostic request 
In stq> 2418. object RtOnmnlliag builds the message to be sent and issues a ScndReqnest to 
RtRocReqRespS crvicc to send the message to the remote device. In stq) 2420, olgect RtCbmmDiag issues a 
waitForRespmise to the aRtRocMcssage instance created for the diagnostic request message. In stq) 2422, 
object RtRocReqRespService pcxforms a scnd.msg on the instance of aRtDevlceConnection associated 
with the remote device. In stq> 2424, the aRIDeviceConnection instance transmits the request message to 
the remote device. In step 2426, objea RtDeviceOmnection m the remote device receives the message and 
issues a handlelnbomidMessage 1o the aRtDeviceConnection instance assodated with the sending device. 
In stqi 2428, the aRtDcviceCmunectioiB instance passes the message off to RtRocRouter via the Rmite 
method for processings In step 2430, obiect RtRocRouter lesp^ 

ProcessInboundReqResp to the RtRocReqRespService. In step 2432, the RtRocReqRespService 
determines the message tjrpc ftom the request message ID and issues a perform command on the 
RtRocDevConDlagListMsg message, in step 2434, RtRocDevConDiagLtstMsg sends a GetDiagUst 
message to object RtDeviceConnection to get the device connection diagnostic data for the device 
connections in this device. In step 2436, object RtDeviceConnection puts the diagnostic data into a data 
buffer using vahous fill routines provided by the utility dass RtDevConDiaglistData. In step 2438, 
RIRocDevConDiaglistMsg then performs a CreateReqionse to create the re^nse message containing the 
diagnostic data. In stq> 2440, RtRocDevConDiagListMsg issues a storeOn message to 
RtDevCouDiaglistData to put the diagnostic data into the response message. In step 2442^ 
RtRocDevConDiagListMsg sends the response message back to the requesting device through 
RtRocReqRespService uang the SendResponse method in step 2444, RtRocReqRespService performs a 
send.msg to the aRtDeviceOmnection instance associated with the requesting device. In step 2446, the 
aRtDevkeCoDDCction instance transmits the response message bade to the requesting device. In step 2448, 
the aRtDeviceCoimection instance in the requesting device receives the response message ftom 
RtDeviceCoimectioii via a liaadteLilKnindMessage* The response message is then send to RtRocRirotcr 
using the Route mmhod. Instep 24S0, RlRocRonter performs a PivcesainboandReqReap on 
RtRocReqRespService. in step 2452, RtRocReqRespService informs the aRtRocMcssage instance that the 
response to the original request for diagnostic data is available. In step 2454, RtCommDiag issues a 
readFrom to RtDevCfmDiaglistData to retrieve the diagnostic data from the re^nse message. In stq> 
2456, RtCommDiag passes the data back to the Diagnostic Application which issues getData messages to 
RtDevCouDiaglistData to retrieve the diagnostic data for display. The requesting device returns a buffer 
containing the general diagnostics for all device connections actively in place. 
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Referring to FIGURE 25, an object comnumtcatioii diagram illastrates a method for requesting 
device comiection communications diagnostics. A diagnostic plication program requests, accesses and 
displays the detailed status of a single device connection existing in a remote device. The diagnostic 
qiplication program sends a request for device connection statistics information to the remote device and 
waitsforarespcmse. Once the reqxmse is roceivBd, the device connection statkics for the deW 
aie display to the user. In step 2S10, a lUagnostic Application program sends a GelDeviceOmlHagB 
leqittst to Rt Cbm mBiag to get the device connectioa statistics for a specific device omnection in the remote 
device. In stq> 2512, RtCommDIag sends a GetDeviceCoonectionlhdex message to Rtl^evkcCoimeclion 
to get the device connection table index for the remote device. In stqp 2514, RtCommDiag issues a Create to 
RtRoeMcssage to create a message to be used to request the diagnostic i nfoimatioa In stq> 25 1 <», 
RtRocMessage creates a new instance of aRtRocMessage to be used for the diagnostic request In step 25 18, 
mCommDiag builds the message to be sent and issues a SendReqnest to RtRocReqRespService to send the 
message to the remote device. In step 2520, RiCommDIag issues a waitForRcsponse to the aRtRocMessage 
instance created for the diagnostic request message. In step 2522, RtRocReqRespService peiforms a 
send^msg on the instance of aRtDevii^Ccmnectlon associated with the rvanote device. In stq> 2524, the 
aRtDeviceConnection instance transmits the request message to the remote device. In stq> 2526, 
RtDeviceConnection in the remote device receives the message and issues a handlelnbonndMessage to the 
aRtDeviceConnection instance associated with the sending device. In step 2528, the aRtDeviceConnection 
instance passes the message to RlRocRouter via the Route method for processing. In step 2530, 
RtRocRooter deierinines diat the message is a request reqxmse type message and issues a 
ProccsslnbottndReqResp to the RtRocReqRespService. In stq> 2532. the RlRocReqRe^rvicc 
determines the message type from tl» request message ID and issues a perform command on the 
RtRocDevConDiagDetailMsg message, in stq> 2534, RtRocDevConDiagDetailMsg sends a 
GetDiagDetail message to RtDeviceConnection to get the device comiection statistics for the requested 
device connection. In step 2536, RtDeviceConnection puts the diagnostic data into a data buffer using 
various fill routines provided by the utility class RtDevConDiagDetailData. In step 2538, 
RtRocDevConDiagDetailMsg performs a CreateResponse to create the response message containing the 
diagnostic data. In stq> 2540, RtRocDevConDiagDetailMsg issues a storeOn message to 
RtDevConDiagDetailData to put the diagnostic data into the response message. In step 2542, 
RtRocDevOmDiagDetailMsg sends the response message back to the requesting device through 
RtRocReqRespService using the SendRcsponse method. In step 2544, RtRocReqRespService performs a 
send_msg to the aRtDeviceConneetioia instance associated with the requesting device. In stq> 2546, the 
aRtDeviceConnection instance transmits the response message back to the requesting device. In stq> 2548, 
the aRtDeviceConnection instance in the requesting device receives the response message fiom 
RtDeviceConnection via a handlelnboundMessage. The response message is sent to RtRbcRmiter using 
the Route method. In stqi 2550, RtRocRouter performs a ProcessInbonndReqRe^ on 
RtRocReqRespService. In stq> 2552, RtRocReqRespService informs the aRtRocMessage instance that the 
le^xmse to tiie original request for diagnostic data is available. In s(q> 2554, RtCommDiag issues a 
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mdAnom to RtPcvConDiagDctallData to retrieve the diagnostic data from the response message. In step 
255^, RtCommDiag i>as5es the data bade to the Dia^iosdc Application which issues gdData messages to 
RtDcvConDiagDetailData to leUieve the diagnostic data for display. 

Gcoeiany, a contioUei/ multiplexer 1 10 is manual^ added to a network. For exanq^ a device is 
Qrpicalfy added to a networic when a user selects the ACN Segment onto which the device is to be corniected 
and issues a 'New Device' command The user is prompted for the device ^pc, either workstation or 
oontiDllei/muItiplexer» the device name and a cmnmem field. A configuration system automatically assigns 
the next Device ID to the device and builds a de&uh name based on the Optionally, Uie 

configuration system automatically generates priniatv and seoondaiy IP a 
device based on PCN number and the jnrevionsly assigned Device ID. 

Ahematively, a controllei/ nndtiplexer is automatically sensed and incorporated into a ron-time 
system as shown in FIGURE 16. In step 2610, a cantrollei/ multq[>lexer, upon connection to the ACN and 
qipticaticmofpower^antamaticany sends a request for idexi^^ Xhe 
reqmst message incfaides the MAC address of the controller/ multiplexer. The request is handled by a 
''PlugftPlay Netwoifc Configuratimi Semce", whidiis knownin the operating system ait, at a mast^ 
configuration controller/ nmltiplcxer in step 2612. In step 2614, the Tlug&Pl^ Netwodc Configuration 
Service" receives the request from the network to assign/ verify an IP address, searches a table of configured 
devices for a MAC address match. If a match is found, in stq> 2616 the "Phig&Play Network Configuration 
Sdvice" responds with the Device Name, Device ID, IP Address Information, Subnet Mask Information, 
ACN Segment Number and other items inchided in the Device Table. If no match is found, in step 2618 the 
Tlug&Play Netwoik Configuration Service" automatically generates a default name for the device based on 
the controllei/ multiplexer MAC address (for example, Controfia-OOO^ The new device is added to the 
database in a Device Scratch area in 5tq> 2620. 

In step 2622, using the Esqilozer^ a user selects each unassigned controUec/ multiplexer in the 
Device Scratch area, drags the selection to the appropriate ACN segment and, and dther adds the selection to 
the system as a new device or drops the selection to a pre-existing device oonfi^ If the unassigned 
controllet/ multiplexer is added as a new device^ the configuration processing proceeds in the manner of 
manual incoiporation of the device. In step 2624, a user is prompted for the real device name nsixig the 
previously assigned name 'ControUer-OOOOOr as a delanlL If automatic address assignment is set, the new 
device is assigned the next Device ID and associated IP addresses and Subnet masks are automatically 
assigned in stq> 2626. If nmual address assignment is set, the device is automatically assigned the next 
Device ID and the user is prompted to enter the IP Addresses and Subnet Masks in sti^ TheMAC 
address fixr the controller/ multiple}Kr is set to the MAC address of the 'ConttoUer-OOOOOr as dragged into 
theACNs^mcnt The new controller/ multiplexer Name, Dewce ID, IP Addiegg, SiAn<>t Ma^^ a« d ACN 
number are added to the device table in the database, llie next request by an onccnpfigured controller/ 
multiplexer is answered by the "Plug&Pi^ Network Configuration Service* . 



-50. 



PCTAJS98/01S73 



If a new contnmer/ multiplexer is dragged and dropped over an existing device, that device must be 
a conrollci/ multiplexer ^dence and have an Accordingly, the MAC address 

of the previoii^ entered controller/ mi]ltq)lexer is set to the MAC address of the 'ContcDUer<<K)0001 ' device 
wAich was dropped. The new controliec/ multiplexer Name, Device ID, IP Addresses, Sidmet Ma^ and 

ACN muiOier are available to sending to the requesting controUei/ multq^ 
Configuration Service^. 

The digital control system program 1 15 includes an auto-configure routine fijr automatically 
confi^iririg the inpnt/oo^rat (I/O) snbs^ystem in lesiMmse either to an ''auto-configure*' command by a user or 
in response to detection of a new oontndlei/nniltiplexBr. 

Refening to FIGURE 27, a flow chart iUustrates steps of an aut<Mnatic configuratwn routine for 
configuring a pJ^sical I/O device. An auto-configure command may be directed to a Controller/Multiplexer 
1 10, cauaog each I/O sobssrstem in the ControUer/Muit^lexer 110 to auto-configuie. An autOKxmfigure 
cmnmand may be directed to an I/O stduystem, causiiig e^ 
configure. An auto-oonfiguie command ms^ also be directed to an I/O Card. 

The auto<Qnfiguie c^ration for an I/O Card fi rst interrogates the I/O Card at a particular card 
position to determine a Card T^pe in step 2710 and, impliday for some I/O Cards, the number of I/O Ports in 
the I/O Card, no yo Card is previous iareated in the engineering database fo^ 
Card oftheapprq)riatet)fpe is defined and the {^ypropriatermnto If 
an I/O Card does exist in the engineering database for that card position, but the Card 1>pe in the 
engineering database does not match the Card Type saised at the card position, the auto-confignte operation 
generates a graphic notification of the mismatch in step 2714 and interrogates a user to detennine whether 
the engineering database is to be changed to include the sensed Card Type. The Card Type in the engineering 
database is dianged to the sensed Card Type in step 27I6if requested by the user. 

Onoe the Card is known, the auto-configuration program intenogates eadi I/O Pbrt in 
axordancc with the Card Type in stq> 271« to determine the Port T^pe and. if information is available, the 
number of I/O Devices on the I/O Port. If no I/O Port is previously created in the engineering database for 
that port address, an I/O Port of the ^ipropriate type is defined and the ^propriate number of I/O Devices 
are created in step 2720. If an I/O Port exists in the engi neering database for the Port address, but the Port 
1^ does not matcA the Qpe of the sensed I/O Port, the user is notmed of the mi^ 
asked wfac^ the oigineering database is to be dianged to match die sen^ 
lype in the eqgine«ring database is (^g?cd to 

Once the Port T>pc is known, the auto-configuration program intoxogates each I/O Device in 
accordance with the Port Type in step 2728 to detennine the Device Typt. If no I/O Device is previously 
created in the eqgineeting database for that device address, an I/O Device of the appropriate type is defined 
instq»2730. Ifan I/O Device eidsts in the engineerit^ database for the Device address^ 
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Type does not matdi tiic type of the sensed I/O Device, the user is notified of the mi-qnatch in icrep 
as&ed whether the eogineediig database is ID be changed to match the sensed 
Device l>pe m the eogioeediig database is changed to the sen^ 
the user. 

In step 273S, instniment signal tags (ISTs) arc automalicalty created for primary signal sowces on 
the I/O Pons and I/O Devices, unless an 1ST already exists with the identical signal souice path. 

Rtf erring to FIGURE 28, a fnmtHif-scieen &sf^y, also caUed a "scieen" 2800, for a graphical user 
interface (GUI) dqncts a display of a system configuration. The screen 2800 dq>icts navi^on sdectioiis 
which ate operated by a user to select, construct and operate a process control configuratioa The navigation 
program siqjplies an imtial state for navigating across various tools and processors in a netwodL A user 
controls the navigatum program to access fihraries, areas, process control equipment and security operations. 

The illustrative system configuration is described and controlled with respect to a control system 
setup 2802, control strategies 2804, and a physical setup 2806. The functions of automatically sensing and 
automatically configuring a control system relate to the physical setup 2806. In particular, the functions of 
automatically sensing and automatically configuring physical devices in a control system relate to the 
commission and activation of devices in the control network 2808, and the decommissioning of controllers 
2810. 

bi an illustrative embodiment, a process control system controls various devices attached to a 
process control network in accordance with a Ficldbus standard protocol. In the Fieldbus protocol, a standard 
user application is defined based on blocks. A block is a representation of various different types of 
application functions. TVpes ofblocksindude resource blocks; iimction blocks, and tiaiis^^ 

A resource blodc describes characteristics of a fieldbus device such as a device name, manufacturer, 
and serial number. A device indndes only a single resource block. 

A function block d^es the control system behavior. Input and output parameters of function 
blocks may be linked over the fieldbus. The execution ofeadifimcticm block is predsety scheduled. Auser 
application may indude numerous function blocks. Examples of standard function blocks include analog 
input (AI), analog output (AO), bias (B), Control Sdeaor (CS), Discrete Input (DI), Discrete Ou^t (DO), 
Manual Loader (ML), Proportiona]/ Derivative (PD), ProportionaV Integral/ Derivative (PID) and ratio (RA). 
Inmctionblodcsaroboih into fieldbus devices to define a sdeaed device fu^ In tme exanq>Ie, a 

single tenqveratmctransmittex may cmitain an Alfimctionblo^^ A control valve often inchides a PID 
function block and an AO falodL 

A transducer blodc decotq)les fimction blocks from local input and ou^t functions for reading 
sensors and c ommandin g output hardware. Transducer blocks contain information such as calibration daU 
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and sensor type. l)l>ical}yattser2Q)p]icationttsesonetnuasducerbIod^ 
block. 

Another object defined in the user plication indodes link objects for defining the links between 
function block inputs and outputs internal to the device and aaoss the fieldbus network. Trend objects allow 
local trmiing of function block paiameteis for access by other devices. Aleit objects are used to allow 
rqKnting of alarms and events on the fiddbus. View objects aiepredefined groupings of blodc parameter 
sets that are used in the famnan/madiineinterfiioe. The function blodi specification defines four views for 
each type of block. 

Referring to FIGURE 29, a state transition diagram illustrates the various states of a field device. 
The field device states indude an ofiOine state 2902, an unrecognized state 2904, a standby state 2906, a 
oonmiisdoned state 2908, and an unbound state 2910. Thestateofafidddeviceisdetoininedbyseveiial 
parameters inchiding a system management state (SM-State), a physical device tag (PDrTag), a device 
address, device revision information (Rev*), and a device identification (Device-ID). In the ilhistrative 
embodiment, a device in the commissioned state 2908 is a Fiddbos device that is avulable for control 
strategy configuration and installation. A decommissioned device is a device that has been removed from the 
commissioned state 2908. 

Several events occur that generate a state transition of a phnali^ of state transUions Tl through 
TI4. One or more actions arc petfonned during each state transition. 

A state transition Tl is caused by the event in which a fidd device residing at a temporary address is 
queried with a system management identify sendee (SM-IDENTEFY) and the queiy detennines that the 
device has a cleared physical device tag. The state transiticmTl changes firom a NULL state to an OFFLINE 
state by allocating a standby address for the fidd device. Executing logic, typically in the form of finnware, 
software, or hardware, executes a set physical device tag sovicc (SET^-TAQ to set the physical device tag 
identical to the device identification of the fidd device. Executing logic also uses a set device addiess service 
(SET-ADDRESS) to send a standby address to the fidd device. 

A sute transition T2 is caused by the evem in which a fidd device residing at a tenqwtaiy address is 
queried with a system management identify setyice (SM-IDENTIFY) and the queiy rfg#t>nni«pc that the 
device has a i%sical device tag that is identical to the device idoitification of the device. The state transition 
T2 changes firom a NULL state to an OFFLINE state by allocating a stsaOtry address for the fidd device. 
Executing logic uses a set device address sendee (SET-ADDRESS) to send a standby address to the field 
device. 

A state transition T3 is caused by the evem in which a fidd device residii^ at a temporal^ 
queried with a system management identify sendee (SM-IDENTIFY) and the qneiy detennines ^ the 
device has a physical device tag and a device identification configured for the current pnxess confiol system 
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netwoiklinL The stale transition T3 changes from a ^mlX Jtote to an O 

that employs the set device address seivicc (SET-ADDRESS) to send an assigned address to the field device. 

A state transition T4 is caused by the event in wMch a fidd device residing at a te^ 
queried with a system management identify seivicc (SM-IDENTIFY) and the query determines that the 
device has a physical device tag and a device identification not configmed for the cunent process control 
system network link. The state transiticm T4 chanHCS from a NULL gtatc an irNRPrYtfi UiTKn ^^f^ 

A state transition T5 is caused by an evem in which the deWce syipeais at a ten^ 
the device is being cornnusaoned by a user. The state transiaon TS dianges fi^ 

OFFLINE state using executing logic, typically in the form of firmware softwaie, or hardware, that executes 
a set physical device tag service (SET-PD-TAG) to dear the physrcal device tag of the fidd device. 
Executing logic also executes a set physical device tag sendee (SET-PD-TAG) to send an assigned pl^sical 
device lag to the fidd device. Executing logic further uses a set device address service (SET-ADDRESS) to 
send an assigned address to the field device. 

A state transition T6 is caused by an event in which the device appears at a tenqwrary address and 
the device is bdng decommissioned by a user. The state transition T6 changes from an OFFLINE state to an 
OFFUNE state using executing logic that executes a set pineal device tag service (SET-PD-TAQ to dear 
the physical device tag of the fidd device. 

A state transition T7 is caused by an event in which auser requests to place a decommissioned 
device in standby. The state transition T7 changes from an OFFLINE state to an OFFLINE state by allocating 
a standby address for the field device. Executing logic executes a set physical device tag service (SET-PD- 
TAQ) to set the physical device tag identical to the device identification of the field device. Executing logic 
also uses a set device address service (SET-ADDRESS) to send a standby address to the fidd device. 

A state transition T8 is caused by an event in which the fidd device appears at the standby address. 
The state transition T8 changes from an OFFLINE state to a STANDBY state through executing logic that 
reads device revision information from the resource block. 

A state transition T9 is caused by an event in which the fidd device appears at the assigned address. 
The Slate transition T9 changes from an 0FFIJD4E state to a COMMISSIONED. 

A state transition TIO IS caused by a user requesting to coinmissiQn a device in the STAh^ 
The state transition T 1 0 chai^ fiom the STANDBY state to the OFFLINE sute throu^ executing logic 
that uses a dear address service (CLEAR^ADDRESS) to dear the device address. 

A state transition Tl 1 is caused by a user requesting to deoommissian a device in the STANDBY 
stm& The state transition TU changes from the STANDBY state to the OFFLINE stated 
logic that uses a dear address service (CLEAR-ADDRESS) to dear the device address. 



W09fl/3fi335 



-54- 



PCTAJS98AM573 



AslateiraiisitioiiT12 is caused by a user requesting to decommissioiia deviceinthe 
COMMISSIONED state. The slate transitioii T12 changes from the COMMISSIONED slate to the 
OFFLINB state thnmgh exBcudng logic that uses a clear address service (CLEAR-ADDRESS) to clear the 
device address. 

A state transition T13 is caused by a user requesting to deconrniisa^ 
state of the FMdbus system management states. The state transition T13 changes from the 
UNRECOGNIZED state to the OFFLINE state through executing logic that executes a set physical device tag 
service (SET-PD-TA<9 to dear the physical device tag of the lidd device. 

A state transition T14 is caused hy a usw icqoestiBg to decominisaon a dc^ 
OPHUTIONAL state of the Fid(fims system managonent states. The state ttansition T14 changes from the 
UNRECOGNIZED state to the OFFLINE state through executing logic to 
(CLEAR-ADDRES^ to dear the device addiess. 

In accordance with the Ficldbus standard, to operate properly a Fiddbus device has a unique device 
address (network address) and a unique plo^cal device tag. Each device connected to the process control 
system network Jink has a unique node designator, A data link specification specifies a range of aUowable 
vahies for node designators induding a range for pamancnt devices, a range for lemporaiy addresses, and a 
raiige for visitor devices. The tcnqroraiy Addresses are used by devices that are not present^ in the S 
OffiRATIONAL state. The Fiddbus inteil^ce maintains partitioning of the addiess space for pennan^t 
devices into three sets. One set. caHed "assigned addresses", indudes addresses assigned to devices with a 
spednc physical device tag, regardless of whether the device is present on the bus. The assigned addresses is 
assigned using a software engineering tool on the basis of information input by a user relating to Link- 
Active-Scheduler takeover preference. A second set, termed "standby addresses", describes devices in the 
SM^^PERATIONAL state but have no device addresses assigned The standby addresses arc managed by 

the Fiddbus interface. The third set ofaddrcsscs arc addresses outside the first and second sets and ref^ 
muised addresses. 

The smaU number of lemporaiy addresses complicates autosensing and online address assignment 
Standby addresses are defined and utUizcd to siqipoit fimctionatily of the autosensing and online address 
assignment operations. The assigned address set and the standby address set are defined to be equal to the 
mmteofpot«aitiddcvicesconnccledtotheprocesscontrolsystemneu^ For example, if sixteen 
devices m^ be potcntidly connected to the process control system netwo^ 
are defined and sixteen standby addresses are defined. 

The device revision information indudes a mamifecturcr's identification (MANUFAC-ID), a device 
|ypc(DEV.TYPE). a device icviaion(DEV4lEV) and a device description revision (DD-RBV). 
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In the GflOiiie Slate 2902 a fi^ dcme Is lecenily ada^ 
inthepn)oessofbeti|gcomiii]Ssioiiedord^ The cxfiOine state 2902 includes device states 

having a phirality of parameter oombjnation?;. In a fiist offline stale 2902, the sjfstem nianagemeni state u 
U^^N^1ALI^D and the physical device tag is cleared. In a second offline state 2902, the system 
management state is INmALI2XD and the physical device tag is read £rom the pineal device and 
displa^ble on a screen. In either of the ofOine states 2902, the device address is a ten:y)oraiy address, the 
revision infomiation is not availably and the device identification is read from the device and displayable on 
the screen. 

In the unrecognized state 2904, the fidd device physical device tag and the device identification do 
not match the values that are commissioned for a device that is connected to the process control system 
network. The utirecognizsd state 2904 iiicludes device states having a pluratiiy of paramet^ 
in a first unrecognized Slate 2904, the system management slate is INT^ 
is a tenqnnaiy address. In a second unrecognized state 2904, the aystrai management state is SM- 
OPERATIONAL vidth a device aiUress that is a slandliyaddiess or an as^ Ineither 
unrecognized state 2904, the physical device tag is read from the device and displaiyable on the screen, the 
device revision is not av^lable, and the device identification is read fi^om the device and diqdayable on the 
screen. 

In the standby state 2906, the fidd device is not yet autosenscd and is therefore not available for 
configuration in the control strategy or induded in Link-Active-Schedolcr (LAS) scheduks of the syston 
management configuration. In the standby state 2906, function block execution and link communications are 
disabled. Note that a Link^Active-Schedulcr is a deterministic centralized bus scheduler that includes a list 
of transmit times for all data bufiecs in all devices that are to be cyclically transmitted. When a device is due 
to send a data buffer, the Link-Active-Scheduler issues a conq>d data (CD) message to the device. Upon 
leceqit of the CD message, the device broadcasts or "publishes* the data in the buffer to all devices on a field 
device bus and the broadcasting device is defined to be a "publisher". Aiiy device that is configured to receive 
the data is defined to be a "subscriber*. Scheduled data transfers are ^ically used for the regular, ^lic 
transfer of control loop data between devices on the fiddbus. 

In the standby state 2906» the system management state is SM-OPERATIONAL, the physical device 
tag is equd to the device identification, aiid the device address is a staiidfay address. The device revision 
informafion is read fioffl the fidd deWce and displayable. The device identification is read fiom the device 
and displayable on the screen. 

The unbound state 29 10 is a configunOion placeholder for a fidd device that is to be physically 
attached subsequently. The imbouiid state 2910 siqipoits configuration of control strategies util^ 
fimctionblocte in a fidd device that is not yet connected. In the untxmnd state 2910, the sfystem 
management state is not yet applicable bat the fdiysical device tag is specified by a user and fiie device 
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addiess is assigned by the user* The device revision infonnatioa set aocoiding to the most recent commission 
or configuration. The device identification is cleared. 

In the Gommissicmod state 2908» the iiehi device is available for control strategy coDflginatiQn and 
installation. The system management state is SMOPERATIONAI^ the physical device tag is q)edfied by a 
5 user, and the device address is assigned by the user. The device revision informatiDn is read finom the field 
device and displayaUe on the screen. The device identification is read firom the field device, stor^ in a field 
oonfiguradon database, and dispk^le on a dtspl^ screeiL 

Several operations or *\xsc cases^ are d^ned Sot controlling commissiottiiig and decommissioning 
of field devices. 

10 Refenring to nCURE 30, a flow chart illustrates a first operation or '^e case" which describes an 

operation ofcommissioning a new device 3000. to the commissioning ofthe new device^ the Fiddbos 
inlerfice is operalionaL A device is connected to the process oontrd system netwoifc. The device either has 
no physical device tag or has a physical device tag that is equal to the device identification. 

The opnatioa of commissioning a new device 3000 results in a condition in whidi the device is 
1 5 assigned a new i^ysical device tag and a device address, and the device is ready for function block 

configuration. The new field device is entered into the process conUol system nctwoik database with the 
device identification bound and the device revi^on information set An engineering softwaie tool that 
^splays the process contr«d system network status diq)]ays the new device as a COlvfMISSIONED device. 

In a first stc^ 3002, the field device appears in the "live list** at a tempoiaiy address. A "live list" is 

20 a list ofall devices that are pioperfyreiqmnding to a pass token (PT) message. All devices on a fiddbus are 
aUowed to send unscheduled messages between the transmission of sdieduled messages. The Link- Active- 
Sdieduler grants pennission to a device to lise the fiddbus by issuing a pass token (PT) message to the 
device. When the device receives the PT, it is allowed to send messages until the messages arc complete or 
until a maximum allotted token hold time has e?q)ired. As a highest priority activity, the Link- Active- 

25 Schedulo^ accesses a CD schedule containing a hst of actions that are set to occur on acidic basis. Ata 
scheduled lime, the link-Active-Scfaeduler sends a con^ data (CD) message to a specific data buffer in the 
fiddbus device. The device immediatd^ broadcasts a message to all devices on the fieldbns. TheLink- 
Active-Scheduler peifoxms remaining cqperations between sdieddedtransfm. Thelink-Active-Schednler 
oontinudly adds new devices to the fidd bus by periodicafiy sendii^ probe node (P^ 

30 that are not on the live list Ifa device is presem at the address and receives the PN, the device immediatdy 
returns a probe response (PR) message. If a device responds with the PR message, the Link*Active-Schednler 
adds the device to the live list and confirms by sending the device a node activation (NA) message. A device 
remains on the live list so long as the device responds properly to PTs. When a device is added or removed 
fnan the live list, the Link-Active-Scheduler broadcasts changes to the live list to all devices to allow each 

35 device to maintain a current copy ofthe live list 
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In a second step 3004, the iotedaceqaexies the field device using a system 
service (SM4DENTIFY) and detecmines whether the fidd itevioe is in the UNINHIAUZE^ 
ph^cai device lag set cxr in the ]NmALIZQ> state having a iriiys^ 
identification. The interface then allocates 3006 a standby address for the field device. 

A logical stq> 3008 directs that a previously UNINIHALIZED device, in stq> 3010, sets the physical 
device tag of the field device identical to the device identificafion using a set physical device tag service 
(SET-PD-TAGXtherdgrpladng the field device in the INITIAL^^ The standby address is sent to 
the field device 30 12 using a set address service (SET-ADDRBSS), advandi^ the field device fiom the 
INTTIALI^D state to the SM-0I%RATlONAL state. At this pofaxt the field device ^ipears in the "live list" 
at a standby address 3014. Device revision infonnation is read fiom the resouioe block 3016. Instep3018, 
an executirig software engineering tool di^lays the field device as a STANDBY device. 

In step 3020, a new user assigns a new physical device tag to the field device. The physical device 
t^ is constrained to be uniqoe aiul not the same as the device identificatioa During the assignment of the 
physical device tag, a device address is assigned to the field device using a software engineering tool and the 
Link-Active-^chediiler takeover preference is set to "selectable**. The device revision information is read 
from the field device and writt^ to the process control system network database. The inteifiace changes the 
state of the field device 3022 to the INITIALIZED state using a clear address service (CLEAR-ADDRESS). 
The field device appears in the "live lisf ' at a ten^Mrary address 3024. 

In a step 3026, the interface queries the field device using a system management identify service 
(SM-IDENTIFy) and recognizes the field device by the device identification. The interface uses the set 
physical device tag service (SET>PD-TAG) to clear the physical device tag 3028, thereby changing the field 
device state to the UNINITIALIZED state. The set physical device tag service (SET-PD-TAG) is then used 
to send fiie assigned ph^cal device tag to.the fidd device 3030, changing the field device state to the 
INmALIZED state. The set address service (SET-ADDRESS) is caUcd to send the asrigoed address to t 
field device 3032, pladng the field device in the system management operational state (SM- 
OPERATIONAL). The field device sqipcars in the "live list" at the assigned address 3034. In the process 
control system network database, the device identificafion is boui^ 3036 to the device. The software 
engineering tool displays the field device as a COMMISSIONED devke. 

Referring to nCURE 31, a flow chart ilhistrates a second operation or ^ 
an operation of comnussionii^ an unbound device 3100. Prior to the oommissioiiiiig of the unbound device; 
theHddbnsiiiteifiKeisQperatkniaL A fieiM device has been created in the process coritrol system network 
database and a physical device tag and a device address are assigned to the field devi^ However, the field 
device is not bound to a device identification. The process control system network database has also been 
initialized to contain device revision information read from the field device. A software engineering tool 
displays the field device as an UNBOUND device. The UNBOUND device to be commissioned is either a 
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fidd device with no physical device tag or a field device having a physical device tag that is identical to the 
device identification. The UNBOUND field device is commissioned to place the field device on tl^ process 
control system network link. 

The operation of oonunissioaing an UNBOUND device 3100 results in a condition in which the 
device is configured with a physical device tag and an assigned device address, and the device is ready for 
function hlockconfigniationL The new field device is entered into the process control system n^woik 
database with the device identification bound. An engineering software tool that displays the process control 
s^^em-netwoik status display the device as a COMMISSIONED device. 

In afirst step 3102. the field device appears in the *^ fist" at a tenqxnaiy address, bi a second s^ 
3104, the inteiface queries the field device using a system managemait identify service (SM-IDENTIFY) and 
determines \iiiether the field device is in the UNINITIALIZED state with no physical device tag set or in the 
INITIALIZED state having a physical device tag that is equal to the device identification. The interfece then 
allocates 3106 a standby address for the field device. 

A logical step 3108 directs that a previously UNINITIALIZED device, in step 3110, sets the physical 
device tag of the field device identical to the device identification using a set physical device tag service 
(SET-PD-TAG), therdiy placing the field device in the INTIIALIIED state. The standby address is sent to 
the field device 3112 using ai set address service (SET-ADDRESS), advancing the field device from the 
INITtALIZED state to the SMOPERATIONAL state. At this point the £dd device ^ipears in the "live list" 
at a standby address 3114. Device revision mformatian is read firom the resource block 3116. In step 3118, 
an executing sofhvare enginemng toed displ^ the fidd device as a STANDBY device. 

In step 3120, a user assigns a physical device tag to the field device by associating the field device 
with the pie-configured device. The device revision infonnation is read horn the field device to ascertain that 
the infonnation matches the device revision infonnation in the process control system netwoik <<atabase for 
the pro-configured device. If the device revidon infonnation of the device does not match the database, the 
user may ovciride the database; reading the device revision information fkam the fidd| device and writing the 
information to the process control system network database. Altcmaavely, the device revision information 
for an UNBOUND device may be made blank, allowing any physical device to be bound with the UNBOUND 
device. The interface changes the state of the field device 3122 to the INITIALIZED stale using a clear 
address service (CLEAR-ADDRESS). The field device ^spears in the "live lisT at a tenqxnary address 3124. 

In a step 3126, the interface queries the fidd device i«i«g a gygfgm mat^agfrofnt Identify Sfrrice 
(SM-IDENTIFY) and recognizes the field device by the device identification. The interfile uses the set 
physical device tag service (SET-PD-TAG) to dear the physical device tag 3128, thereby changing the field 
device state to the UNINTTIALIZED state. The set physical device tag service (SET-PD-TAG) is then used to 
send the assigned physical device tag to the field device 3 130, changing the field device state to the 
INmALlZED state. The set address senrice (SET-ADDRESS) is caUed to send the assigned address to the 
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field device 3132, placing tbe fidd device in the system management q>aatiQnal state (SM- 
OPERATIONAL). The fidd device appeals in the ''live list" at the assi Inthepiocess 
oontiol system netwoik database, the device identification is bcfund 31^^ ThesofHvare 
engineering tool displays the fidd device as a COMMISSIONED device. 

Refening to FIGUBE 32, a flow chart iUnstiates a third opetation or "use cas^ wfaidi describes an 
operation of decommissiomng a device 3200. A fidd device is decommissioned for several tcasons. For 
exan^le, when a Fieldbus device is obsolete, a user may wish to dear a network inteiconnectian structuie of 
nonfoncdoning branches so that the process control system no longer expends resources on the obsolete 
device. Also, a iiser may suspect that a Fieldbus deWoe is malfimctioning and degia^ 
segment ofanetwQikinteianuttctiQn structure. The user may diagnose the pitiblem by having the process 
Gontrd system ignore the suspected Fiddbus device temporarily to detennine whether the remaining devices 
in the segment operate prqserly. 

Prior to the operation of decommissioning a device, the Fiddbus inlerfacc and the fidd device are 
operafiond and the fidd device a]^)ears in the live list at the assigned or standby address. Asoftware 
engineonng tool display the fidd device as a COMMISSIONED or ST>^ Thesoftwaie 
engineering tool executes a routine that prepares the fidd device for decommissianing, for example by 
clearing fimction block tags and dealing an OP£RATIONAL*FOWERlJP flag. 

The operation of decommissioning a device results in a condition in which the pig^cal device tag of 
the fidd device is deared and the fidd device is prqiared to be removed from the process control system 
networklink. The process control sfystem networic database entiy for the field dencc derignates the devi 
id^tification as in an unbound condition. The software engineering tool displays the device identification as 
an UNBOUND device and displays the physical device as an OFFLINE device. 

Hie operation of decommisrioning a device 3200 begins when a user selects a Decammission" 
opeiation for the fidd device 3202. A graphic iiser interface indudcs a software eqgineeri^ 
a 'l>eo(mun]ssion'* command to an appropriate contn^erwit^^ Tht 
decommission command specifies a target I/O subsystem, card and port identifieis, and the device 
identification of the fidd device to be decommissioned. The device identification is specified since another 
device with the same physical device tag may be present in an UNRECOGNIZED state. The intertace 
changes the state €i the fidd device 3204 to the INITIALIZED state using a clear address seivice (CLEAR- 
ADDRESS). Hie fidd device appears in the ''live list" at a ten^raiy address 3206. 

In a step 3208, the intei&ce queiies the fidd device using a system management identify service 
(SM-IDENTEFY) and recognizes the fidd device by the physical device tag and the device identification. 
The interface uses the set physical device tag service (SET-PD-TAG) to clear the physical device tag 3210, 
therdjy chaiiging the fidd device state to the UNINITIALIZED state. 
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In the pnxxss control system netwoik database, the device identification is unbound and the 
software engineering tool displays the field device as an UNBOUND device 3212. In a next step 3214. the 
software engineexii^ tool displays the field device as an OFFLINE device. 

A neiwodc interface card stores a designation that the field device has been decommissioned 3216 
and does not nuyve the field device to a STANDBY address unless directed by the user. Ifthe 
decommissioned device is not move to a STANDBY address, the int^ace card tracks the field device until 
the field device advances off the live list 

Referring to FIGURE 33» a flow chart illustzates a fbuith operation or **use case** which describes 
an operation of attadung a commissioned de\ice without enablement of operational powerup 3300. Prior to 
the operation of attaching a commissioned device 3300, the Fieldbus interface is operational. The 
configuration of the Fieldbus intei&ce inchides the field dcWcc in an attached conditioa The physical device 
tag and the device identification of the field device are matched. Following the operation of attadiing a 
commissioned device 3300, the fidd device has an assigned address. 

The field device appears in the "live list" at a temporary address 3302. In a stq> 3304. the interface 
queries the field device using a system management identify sovice (SM-IDENTIFY) and recognizes the 
fidd device by the physical device tag and the device identification as part of the Fieldbus interface 
configuration. The sd address service (SET-ADDRESS) is called to send the assigned address to the field 
device 3306, placing tiie field device in the system management operational state (SM-OPi^TIONAL). 
The field device appears in the *^live list" at the assigned address 3308. 

Referring to FIGURE 34, a flow chart illustrates a fifth operation or "use case" which describes an 
operation of replacing a device 3400. A device is replaced by decommissioning the current field device 3402 
connected to the process control system network Hnk, if possible, and commissioning a replacement to the 
UNBOUND device 3404. Tliestq>of decommissioning the current field device 3402 is described in detail 
with reference to FIGURE 32. The step of commissioning a replacement to the UNBOUND device 3404 is 
described with reference to FIGURE 31. 

Referririg to FIGURE 35, a flow chart ilhistrates a sixUi operation or "Sisc case" which describes an 
operation ofattaching an UNRECOQ^nZED device 3m Prior to the operation of attadiing a 
comimssioned device 3300» the Fiddbusintet&ce is operational A field device is attached which has a 
physical device tag and a device identification that is not configured for die conent process control system 
netwoik link. FoUowing the operation of attachiqg an UNRECOGNim> device 3500, the fidd device is 
identified and the software engineering tool di^lays die device as n UNRE(X)GNiaED device. The 
operation of attaching an UNRECOGNIZED device 3500 may be performed witiMmi use of the solhvare 
iengineering tooL 
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The fidd device appeats in the "live list** 3502. In a stq) 3504, the intei£K:e queries the fidd device 
ttsiag a system management identil^ service (SM-IDENTriFY) and detennines that the physical device tag 
and the device identification do not match a field device in the present configuration. 

Referring to FIGURE 36, a flow chait illustrates a seventh opocatioii or *^ case" which describes 
an operation of decommissiQiung an tmiecognized device 3600. Prior to the operation of decommissioning 
an unrecognized device, the Fieldbusintei&ce is operational The fidd device is identified which has a 
plq^sical device tag and a device identification that are not configured for the present process control system 
Dfitnmklink. A software engineoing tool di^lays the fidd device as an UNREO^^ 

The <^)eration of decommissioniiig an unrecognized device 3600 results in a condition in which the 
plQ^cal device tag of the fidd device is deared and the fidd device is prepared to be removed from the 
process control system netwoik link. The sofhi^ engtneering tool di^lays the field deWce as an OFH.INE 
device. 

The operation of decommissioning an unrecognized device 3600 begins when a user sdecis a 
*T>ecommission'' operation for the field device 3602. A gr^hic user interfece indudes a soitwaie 
engineering tool that issues a "Decommission** command to an ^ropriate controller within the process 
control system: The deoommisston command spedfies a target I/O subsystem, card and port identifiers, and 
the device identification of the field device to be decommisaoned. 

If the fidd device is in the INITIALIZED state, logic step 3604 directs the decommissioning 
q>eration 3600 to a dear the physical device tag step 3612. Otherwise, the interface changes the state of the 
fidd device 3606 to the tNITIALIZED state using a dear address service (CLEAR-ADDRESS). The field 
device appears in the "live fisT at a temporary address 3608. 

In a step 3610, the interface queries the field device using a ^stem management identify service 
(SM-IDENrih Y) and recognizes the fidd device by the physical device tag and the device ideiitificafion. 
The interface uses the set physical device tag service (SET-PD-TAG) to clear the physical device tag 3612, 
therdyy changing the field device state to the UNINTIIALIZED state. In a next step 3614» the software 
oigineering tod ^spkys the fidd device as an OFFLINE device. 

A network interface card stores a designation that the fidd device has been decommissioned 3616 
and does not move the field device to a STANDBY address nnless directed by the us^. Ifthe 
decommissioned device is not move to a STANDBY address, the interface card trades the field device nntil 
the fidd device advances off the live iisL 

Referring to FIGURE 37, a flow chart illustrates an dghlh operation or ''use case" which describes 
an operation ofpladng a decornmisdoried device in a standby condition 3700. Prior to the operation of 
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pladog a decoininisa<»ied device in a standi Afield 
device is dcc o mmisa onc d and in the OFFLINE state. 

The operation of placing a deconunissioned device in standby 3700 lesolts in a gmmiti^^n in which 
the field device is placed at a standby addiess ivith the physical device tag of the fidd device set identical to 
the device identification. The software engineering tool displays the field device as a STANDBY device. 

The qieiation of placing a deconunissioned device in standby 3700 begins wh^ 
*nace in Standby^ operation for the field device 3702, A graphic user inieifiiceittchidcs a sdhvare 
engineering tool that issues a "Place in Standby" command to an ^ropiiate conuoller within the process 
control system 3704. The decommission command specifies a target I/O sobsysteai. caid a^ 
and the device identification of the field device to be placed in standby. 

The interlace allocates a standby address 3706 for the field device. The set physical device tag 
service (SET4>D-TAG) is then used to set the physical device tag identical to the device identifkation 3708, 
changing the field device state to the INITIALIZED state. The set address seivice (SET-ADDRESS) is called 
to send the standby address to the field device 3710. placing the fidd device in the system management 
opeiational state (SM^PERATIONAL). The field device appean in the "live list" at the standby address 
3712. Device revision information is read fiom the lesoiuce In slq> 3716, an executing software 

engineering tool displays the field device as a STANDBY device. 

A user m^ subsequently commission the field device 3718, either by creating a new device or 
binding the field device to an UNBOUND device in the process control system network database. The 
techniques for commissioning a device ate desoibed with respect to FIGUREs 30 and 31. 

Referring to FIGUR£ 38, a schematic blodc diagram illustrates a program stfucmre of a process 
control configuration program for defining a process configuration using a plurality of control languages. 
The module editor 3820 is a software program that executes on the CPU 116 within a workstation such as the 
engineering woikstation 106. Using the module editor 3820, a user activates one language editor of multiple 
control language editors indnding an attribute editor program 3830, a Function Block EditMew/Debug 
program 3840, a Se^iential Function Chart program 3850, a Ladder Logic program 3870 and a Structured 
Tcirt program 3890. The multiple omtrol language editors operate with compatible databases and interfaces 
so that a common omtrol strategy is defined usii^ the diffeient control Thelodcandfed 
of the different control language editors is snnilar so that a user easily ^ 
editors for different purposes to best take advantage of different aspects of the lar^guatges. 

The module editor 3820 is the fimdamental ivutiiie for cfmQguiation entry and is used to create, 
edit, and re-use control and equipment module instances and library modules defined by the SP88 standard. 
The module editor 3820 supplies a gnq>hical tedmique for confignring, visualizing and navigating tmiitiple 
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modules that combine to Ibnn a oontroi strategy. The module editor 3820 is also used for module linidng and 
defining module contaiiuiieiit 

The module editor 3820 supplies access to all aspects of configuration of a module inchiding sappoii 
for algorithm definition, as iveU as infoimationgatheiiii^ rdatiAg to alarms, events* faistaiy» condition, lielp, 
ooaqKments and attributes. 

Hie module editor 3820 incJudes various features that laciHtate navigation through a conixol system. 
For example, the module editor 3820 filters attrArotes on usei«4lefined key words to supply a focused attribute 
oonfigniationview. Fmthermore, the module editor 3820 iiicludes a £m itistaU capatnl^ 
performing the iiistall to aU devices afiectedl^ changes to the module. The contid strategy is tiansfentd 
from the editors into runtime engines using an install script A plurality of oontiol language execution 
CTgines execute the control strategy on one or more controller/ nuihiplexets 110. 

Off-line c<H]figurari<m sq>ports Voric in progress' for an existing module's control strategy. When 
the new strategy is complete, it can be installed to the existing module. This * wcnk in progress' can be 
flagged to not allow it to be installed. 

The attribute editor progvam 3830 is a control program operated by a user to view and edit 
parameter values associated with a control module or control algorithm elements including function blodcs, 
ladders, conqwsites, and the like. The attribute editor program 3830 is used on-line to configure a control 
module. On-line, the attiilyute editor program 3830 is used to view and edit data. Attributes are defined to 
liiniish module-level access to parameters contained within a module. The attribute editor program 3830 is 
activated by the module editor 3820 and other control language editors. Hie attribute editor program 3830 
presents a simple attribute configuration view using a graphical navigation tree pathway display to 
consolidate the parameters to be configured for a module. A user activates the attribute editor program 3830 
aiid navigates thnmgh the gr^hical navigation tree to find a particular attiib^^ When an attribute is 
selected, the attribute is ^s^ayed either using an s^lication window or as a dialog depending on the context 
from which the display is evoked. The attribute editor program 3830 £icilitates configuration by supporting 
copy, paste and bulk change of attributes using a drag and drop technique. The attribute editor pr^giram 3830 
is used to define attribute parameter values but not to install attributes since attributes are installed when the 
module containing the attribute is installed. As attribute param^er vahies arc entered by a user, the attribute 
editor program 3830 performs error checking. The attribute editor program 3830 allows a user to sort and 
view data with typical spreadsheet capabilities, including expansion and reduction of the number of columns, 
or by contaimnenL 

The Function Block EditA^ew/Debug program 3840 is a control program operated by a user to 
define a control strategy by assembling function blodt elements designated under the Fieldbus Foundation 
and lEC 1131-3 standards. The function block program 3840 is in^lemeiUed in a function block execution 
engine whidi operates in a controlleE^ multiplexer 110. The function blodc execution engine executes 
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function block control algorithms using a Function Block Libraiy 3842. The function block program 3840 
siqiplies a gnq)hical editor for creating, editing and reusing control strategies using function blocks stored 
within a Function Block Libiaiy 3802 and other defined control modules, for example control modules 
defined for usage by other plication programs. A created control strategy is saved as a leasable libraiy 
5 componem in the Function Block Libraiy 3802 for subsequmt usage or for usage b^ 

program. The function block program 3840 also cieates, edits and reuses control structures f^ 
FF timing field devices. The fimction block and module consthuents of a control strategy ate not confined to 
a particular device* but are rather pattttioned amss multiple oonirol devices^ inchiding HART and FF timing 
field devices. 

10 A function bhxJc or module indudesattnbutes that are modified using the iu^^ 

3840. Any attribute in the sfystem, unless security protected, is accessed through^ 
for that attribute and is read or written firom the function blodc editor. 

The iinution Mode editor program 3840 supports an ofi'-line creation and debug Auction for control 
strategies of inodules and reusable libraiy con^Muients. During off-line operation, a control device is not 
15 connected to the network Offline operatian is usefal for initialinng aftrihHteg pgrameters before the 
control device is connected using an attribute editor 3842 of the function block editor program 3840 since, 
during off-line operation, multiple control strategies can be open, and configurations can be copied and 
pasted between strategies. 

The function bhx^ editor program 3840 also soppoits on-line graphical editing, viewing and 
20 debugging of functions blocks during c^ieration, including display of blodc input and output values. Selective 
on-line edit and debug mode cipttons include single step, forced inputs and brealqpoint options, for example. 
One window is used for on-line editing and debugging so that the user may correct an inconsistent parameter 
value in place. Input values during on-line editing are checked for consistency with off-line editing values, 
and disallowed if inconsistent 

25 Hardcopy output infonnation generated by the fimction block editor program 

g rap h ic al representation and conf^uration infonnation such as block attribute and parameter values. 

Several features of the function block program 3840 ^cilitate user support induding the creation of 
reusable libraiy components, user oQiiversatian support, and input enm* checking. User oonveisation support 
within stq> actions sdkws a user to configure pap-i]q>diaU^ with le^^ Reusable libraiy conqionents 
30 are devdqped to simplify engineering during configuration and execution so that a rin^e Function Block 
Diagram (jFBD) acts as a subroutine for multiple modules or FBDs during execution. 

The Sequential Function Chart (SFQ EditA^ew/Ddmg program 3850 is a control program operated 
by auser to define a ccmtrol strategy by asscndiling steps, slep actions and transitions designated under IBC 
1131«3 standards. The sequential function chart program 3850 i^ implementgrf in an >qFC CTrmtiffn engine 
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vftkh operates in a contiollei/ nraltiplexer 1 10. The SFC execution engine executes sequential function 
chart contiol algorithms including steps, actions and transitions. The sequential function chart prognun 
3850 supplies a graphical editor for creating, editing and reusing sequential control strategies using 
secpie nti a l function charts. The sequential function chart program 3850 supports execution of paraUel logic 
paths. Executing s equ enti al function charts are associated with a module, at least for the duration of SFC 
execution. 

A sequential function chart includes attributes that are modified using the sequential function chart 
program 3850. Any attribute in the system, unless security protected, is accessed from a step in a sequential 
function chart execution. 

The sequential function chart program 3850 supports an off-line creation and ddiug function for 
control strategies of modules. During off-line qperation, a control device is not connected to the networic. 
OfOine operation is useful for initializing attributes and parameters before the control device is connected 
using an attribute editor 3842 of the sequential function chart program 3850 since, during off-line operation, 
multiple control strategies can be open, and configurations can be copied and pasted between strategies. 

The sequ^tial function chart editor program 3850 also supports on-line graphical editing, viewing 
and drugging of sequential fimcdon charts during operation, including a "live" display of attribute values. 
Selective on-line edit and debug mode options include single step, forced inputs and brealqmint options, for 
example. On-line editing includes setting of a brealqxtint for executing a control strategy while changes are 
made in the strategy. One window is used for on-line editing and debugging so that tiie user m^ conect an 
inoonsislent parameter value in place. Input values during on-line editing are checioed for consistency with 
(^•line editing values, and disallowed if inconsistent The sequential function chart program 3850 supports 
runtime view indudtng a display of 5teps» actions, currently-executing transactions and attcOmte values. 

Haidoopy output information generated by the sequ»itial fimction diart program 3850 includes 
giq>hical iiqxresentatton and configuration information such as step actions. 

Several features of the sequential function chart program 3850 facilitate user siqiport including the 
creation of reusable libraiy components; user com^ersation support, and input error checking. User 
conversation support within step actions allows a user to configure pc^up dialogs with responses. ReusaUe 
libraiy CQmponents are devtkoped to simplify cngineeriog dniing configuration and execution so that a single 
Sequential Function Chart (SFQ ads as a sobroutiiie for multiple modules or SFCs during execuAiaa 

The Ladder Logic program 3870 is a control program operated by a user to define a control strategy 
using ladder dements and fimction blocks in combination in a ladder logic diagram. The ladder logic 
program 3870 is inqdemented in a Ladder Logic engine which qioattt The 
ladder logic ei^gme executes ladder control algorithms indudiog €mls» cont 
function blocks. The Ladder Ix»gic program 3870 incfaides a baac discrete control ladder bgiclib^ 
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which indndes the con^xments fa solving basic disoeCe control qieiations. These operations arc logical 
e x tensions of lEC 1131-3 standards incfading donents soch as coils» contacts, timeis, flip/Qops, edge 
triggefsaadoQQiiienswithimeouqpnitconnecti The Ladder Logic program 3870 

also siqipomplacemem of iiser-defined Mocks imth^ A ladder logic diagram is 

qiplicable to a ftmcdon Uock that siq^rts power flow in which the state of execution is determined by 
whether 't^owef' is ikradtigthiDagh a *^g" in the ladder. Power flow is somewhat analogous to data flow 
in a logic diagram. The applicable function blocks, atone^ are displayed I7 
on a ladder logic palette. 

llie Ladder L(^c pit9grara 3870 may be exdnsivdy vsod by a user to CO 
strategy or a ladder dtagim sheet m^ be used as a ooinposite wit^ 

blodc diagram sheet or an sequential function chart sheet A ladder togic sheet can hold composite ladder 
logic diagrams, iimction blodc diagrams or sequential lunctionL diart dieets. A ladder logic element can read 
and write to attributes in other sheets and in other modides. 

I^derlc^ diagrams support both on-line and ofi'-line editing. User can switch from ddmg 
fhnctionali^ to the edit mode on a specific ladder logic diagram to make structural changes in the control 
strategjr. The user may change any parameter from cither the ddrag view or the edit view. 

The Ladder Logic program 3870 Irududes a debug fbnctionali^ that inchides a display of power 
flow, parameter vahies and energized or de-energized states. The ladder logic debug functionality is the 
substantially the same as the debug functionality of the Sequential Function Chart editor program 3850 in 
whidi the user forces input values, sets breakpoints and the like. The Ladder Logic program 3870 supports 
ladcter logic simulation, historical data collection and mode, alarm and status report genoatiorL 

Reiming to FIGURE 39A, a screen presratation of a configuration screen 3900 is depicted whidt 
is generated Iqr a oonfi^tron program usirig the fimctum block editor The configuration screen 3900 
indudes a navigation portion 3902 and a scteen-q)ecific portion 3904. The navigation ptntion 3902 includes 
navigation tabs 3910 which allow a user to access particular sections of the configuration program. In the 
illustrative state of the configuration screen 3900, the configuration ]»ogram is awaiting a user entry of a 
configuration command. Navigation tabs 3910 indicate several primitive functions for the entry into a 
function blodc induding a navigation tab 3912 for sdecting a simple set dommant (SR) flip-flop, a 
navigation tab 3914 for sdecting a simple siditract blodc, a navigation tab 3916 for selecting a simple timed 
pulse blodc, a navigatioti tab 3918 for sdecting a sinqde transfer blodc, and a navigation tab 3920 fa 
sdecting a sin^exdusive-OR(XOR) block. The navigation td)s 3910 also indnde a blodc assistant 3922 
tab for inserting a fimction blodc. The screcn-spedfic portion 3904 illustrates a function blnA 391d that 
to be configured, indudmg configuration of attributes and connections with other function btodcs. 



The blodc assistant 3922 tab is sdected to insert a function block. 
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Refemng to FIGURE 39B, a Sdecticm screen 3930 is dis^ 
insert function block. The sdection screen 3930 also inchidcs a sdcction portion 3932 and a scrccn^^^ 
portion »34, The saeen-specific portion 3934 includes an entiy block 3936 for entering the name of a new 
block tlmt is to be oeated. The selection portion 3932 indodes a pluralitjr of sdecdon tabs 3938 including a 
lonction block 3940 tab, an oidwdded Uock 3942 tab, a finked composite 3944 1^ and a module block 3946 
tab. The selection portion 3932 also inchite a varies of buttons 

indttdiiigaBackbDtton3948,aKe]abmtQn39S0andaCai^ bntton395Z The Badcbotton 3948 takes 
the user to the previous screen presentation in strict historical order. The Next button 3950 takes the user to 
the screen presoilation appropriate for the selections that arc made on the ainent screen p n>c«ftetm " The 
cancel button 3952 terminates the selection. 

The embedded block 3942 tab is selected to insert an oiAeddcd blodiL 

Referring to FIGURE 39C, a Choice screen 3960 is cvdced to allow the user to select a control 
language editor for configuring the embedded block, either a function block editor using selection 3962 or a 
sequential function dsart editor using selection 3964. 

The selection 3964 is chosen to utilize the sequential fuzicticBi diart editor. 

Referring to niGURE 39D, a sqeen presentation of a configuration screen 3970 is ilhistiated in 
winch the function block 3924 is configured usirig the function editor 3840 and a ncwijr oeated block 3972 is 
configured using the seqimtial function chart editor 3850. 

Editing (rfncwty aeated block 3972 is sdected so that the sequential fiinction chart editor 3850 is 

invoked. 

Referring to FIGURE 39E, details of a the newly created block 3972 are shown in the screen- 
q>edfic portion 3934 of the configuration screen 3980 including attributes 3982 and a stq> 3984. The 
navigation portion 3986 of the configuration screen 3970 no longer lists navigation tabs relating to function 
blocks, but iatha: indodes navigation tabs 3988 relating to a step 3990, a transitioa 3992, a teimination 
3994, and ii^ tenninal 3996 and an ou^ tenninal 3998 to define the steps and transitions of a sequential 
function. 

Referring to FIGURE 40. an object model shows object relationships of various objects for handling 
alarm and event functions. Variousconditionsaredefinedtobe"events'*inch]ding Alarms, Alarm 
adcnowledgments, user dia^ges (writing attributes, invddng methods, log-in/out), configuration changes to 
the '^run-time" ^)rstem Onstsdlations, de-installs, etc). Sequential Function Chart (SFC) state dianges. 
Operator Attention Requests (OARs), and other miscellaneous Events (non-alarm state ttanations inchidiog 
eqn^mieiit stale changes). 
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A common chaiacteiisdc for all types of events is that the occmrence or state transition of an event 
canbexecoxdedinaEventJoDinai. M events are associated \vith one (or moie) plant areas. Evoit 
oocunenoe records (RtEventOocmienceRecord 4040) aie captured in the Event Journal, or Journals, 
(RlEvenUouxnal 4020) designated for the associated plant area (RlPlantArea 4010). 

A Jisa activates the Event Joiunal, ^picalty using a workstation^ by configuring one or more Plant 
Areas within which the activated Event Journal o^turcs events. On-line operation of the Event Journal is 
modified under user control hy disabling or enabling qiedfied classes of events to be recorded. 

llie user configures an Alarm behavior by creating Alarm Atn1imes(R^ 
Modules or Equipment Modules OUModule 4030). An Alarm Attribute fiunishesief^ence to atiy boolean 
Attribute within the Control Module or Equipment Module containing the Attribute. Alarm Attributes arc 
created only at the Module level Alarm Attributes are not created in Composite Function Blocks. 

Referring to FIGURE 41, a state transition diagram illustrates alarm attribute states. A user either 
disables or enables an Alarm Attribute. Whra disabled 4110, the Alarm Attribute ^peais in a ^'normal*' 
condition, caUed an ^'liiactive and Acknowledged" condition. The Disabled/Enabled condition of an Alarm 
Attribute is changed either on-line, by an Operator^ or automatically by a control algorithm in the system. 
Hie inttiai Disabled/Enabled condition is at configuration time. An enabled Alarm Attribute has cither an 
Active condition 4116 or 4110 or an Inactrve condition 4112 or 41 14. The Alann is Active ( ^in alarm'') 
m^en the refoenced boolean Attribute is TRUE. The Alarm Attribute is optionalty configured to invert the 
sense of the alarm state, so an Alarm Attribute with .INV characteristic TRUE operates is if the rderenced 
Attribute's vahic of FALSE indicates an **in alarm" conditicm. The Active^nacdve conditiaii is driven by 
the state of the referenced Attribute so that the ActiveAinactive condition is not directly changed by the 
Operator or another control algorithriL 

While Enabled, an Alarm Attribute has dither an Acknowledged 4112 or 4116 or Unacknovdedged 
state 4114 or 4118. The AtamANiilmte is placed in the Unacknowledged condition only i^ 
Attribute makes a transition from Inactive to Active state, unless automatically acknowledged. An Operator 
or another control algorithm ma^y adcnowledge the Alarm, changing the Alarm Attribute to the 
Acknovidedged condition. 

An Alarm Attribute is ^dier automatically acknowledged (AACK'd) or not automatically 
acknowledged. AACK is determined from the current Alarm priority. Auser«€onfigured, systm^wide table 
determines AACK behavior. For example, the table may designate that all "LOW" priority Alarms are 
auiomatcally acknowledged (AACK is TRUE), alt "MEDIUM" and "fflGH^ priority Alarms are not 
automatical^ acknowledged (AACK is FALSE). When AACK is TRUE, the alarm is never placed in an 
Unadcnowledged condition. 
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The combiDed operation of the Enable/Disabled, Active/Inactive, and 
AdmowlcdgcdAJnadaiowledged conditions results in user-visible states for an Alam Attribute that axe 
shown in FIGURE 41, 

An enabled Alarm Attribute initiaUy goes to the Inactive/Adc*d State 4112, and maf immediately 
5 transition to either Activc/Unack*d 4114 or Active/Adc'd 4116. The transition to Active/Adc'd 4116 is 
accompanied by a standard •*transition" behavior for Alarms in whidi Uie transition is timestan^ and the 
event is recorded in the event jounial, for eacample. 

The Alami Attribute has midtq>te fields that provide a A CUALM "cnrrent 

alarm" field is "OK" wfaenthe Alarm Attribute is in the Disabled state 4110, the biactive^Ack'd state 4112 oi 

10 InactiveAJnack'd state 4114. Otherwise CUAlAf is the wordAralue associated with iht configured Alarm 
Type. A DESC "description** field has an alann description that is generated when the Alarm Attribute 
dianges slate. The DESC fidd is initialized to the onpty string. A LAALM "latched alaim** fieJd is "OK" 
when tiie Alarm Attribute is in the Disabled state 41 10 or the Inactive/Adc'd state 41 12. Otherwise the 
LAALMfield is the wordAralue associated with tiw configured Alarm l>pe. The LAALM field presents 

15 "latched" alarm activations, enabling Acknon^gment even ifthe duration ofbeii^ Active is very short A 
NALM 'Sinadmowledged alarm" field indicates the Adoiowledged/Unadmoidedged condition of the Alarm 
Attribute. The NAI^ field is used to determine when alarm summary entries can be ronoved. An^AB 
"alarm enabled** field indicates the current Enabled condition for the Alarm Attribute. An lENAB "alarm 
initial^ enabled" field indicates tiie configured Enabled condition fertile Alarm Attribute AnINV 

20 "inverted irqnit'* field indicates whether the value of an assodated boolean Attribute is inverted before alarm 
processing. The INV configuraible characteristic permits an Alarm Attribute reference nonnally TRUE 
boolean Attrftutes, for exan^le an Attribute holding a discrete input A IW "alarm priority" fidd indicates 
cunent priority(High/Medium/Low)of an Alarm Attribute. TABLE II shows tiie boolean Attributes as 
follows: 



| | TABLE IL_Attribute: (user defined boolean Attribitte) I 













(or none) 


(same as LAALM) 


(same as LAALM) 


(same as 
LAALM) 


(same as 
LAALM) 


CUALM 


Read: [view] 
Write: N/A 
ConfiK: N/A 


"OK" 

(alarm word) 


0 

(alarm type 
number^) 


0 

(alarm type 
number) 


DESC 


Read: (view] 
Write: WA 
Gonfig: H/A 


(description 
goieratedattbe 
time of alarm state 
change) 


N/A 


N/A 


ENAB 


Read: [view] 
Write: (alarms) 
Config: N/A (initio 
lENAB) 


"NO" 
"YES" 


0.0 
LO 


0 
1 




Read- (viewl 
Write: N/A 


"Ncr 

"YES" 


0.0 
1.0 


0 
1 
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Config: (oonfiel 








lENAB 


Read: [view] 


'DISABLE" 


0.0 


0 




Write: N/A 


''ENABLE" 


1 0 


1 
1 




Config: [config] 










Instance ovenideable 








LAALM 


Read: [view] 


"OK- 


(alann type 


(alann type 




Write: N/A 


(alann wont) 


number) 


nnniber) 




Config: N/A 






NALM 


Read: [view] 


''NO'* 


0.0 


0 




Write: (operate) 


"YES" 


1.0 


1 




Config: N/A (init FALSE) 








PRI 


Read: [view] 


•xocr 


3.0 


3 




Write: [alacms] 


1X)W" 


2.0 


2 




Config: [oonfig] 


"MEDIUM" 


1.0 


1 




Instance ovenideable 


"HIGH^ 


0.0 


0 



The process contrcd system 100 consolidates many potential Active Alann conditions into a shoit list 
of "highest priority" alanns. A selection critexia is nsed to select the highest priority alanns for 
consolidation. The selection criteria includes analysis, in oider of decreasing prefoence; the Acknowledged 
condition with the Unacknowledged condition having precedence over the Aduiowledged condition, the 
Alarm Priority in order of High then Medium then Low precedence, and the Time of Detection with the 
newest timestamp gaining precedence. 

Alann Consolidation is available at the SPSS Module level and the Plant Area level. Alann 
consolidation is accessed via a pre-defined Attribute name "ALARMS" available on SP88 Modules (Control 
& Equipment) and Plant Areas. ALARMS is an indexed Attribute, where the index selects the Nth highest 
priority alarm in the consolidation (e.g. ALARMS[1] accesses the highest priority Alarm, ALARMSPI 
accesses the second highest priority Alarm, etc.) Thus, for example, 'AREAI/F1C101/ALARMS[1J' 
rcfetences the highest priority Alarm in Module FIClOl and 'AR£A1/ALARMS[2)' references the second 
highest priority Alann in Plant Area AREAl. The maxinmm index supported on the ALARMS Attribute is 
5. 

The Fields supported on the ALARMS(N] /attribute include the LAALM ''latched alarm" field 
whidi indicates the Active Or Unacknowledged conditions of the Nth priority Alann Attnlnite. The LAALM 
Field is in the alarm word, or alann type vahie, of the Nth priority Alann Attribute during the 
ACTIVEAJNACKT>,ACTrV^ACKT>,ormAClTVEAJNAC^^ The NALM 'Wcknowledged 

alann" fidd indicates the Acknowiedged/Unad{iioi^e4ged o^ 

The PRI "alann priority" field indicates the configured priority (High/Medmm/Low) of the Nth priority 
Alarm Attribute. A TAG "alann Tag" field returns a fiilty qualified Attribute reference string (excluding 
Field) for the Nth priority Alarm Attribute. A MODULE "alarm Module" fidd indicates the SPSS Module 
(tag) whidi has the Nth priority Alarm. The MODULE tag returns a Module reference string which can be 
used to access the ' t^imaiy control displaf. attribute for that Module. 
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Some Fields are supported on the ALARMS Attribute only at the SPSS Module level If an index 
value is applied for these fields, the index value is ignored. The SPSS Module level ALARMS Attnbute 
fields iiulnde an ENAB ''alarm ouOded* field which indicates the corrent Alarm Stabled condition for the 
Module. APIUAD'^primiQra^jastmenr field is a number (nonnaltyO)iiinc^ 
5 PdoiityQfeadi Alarm Attribute in the Modote when determining thee The 
PRIAD Modute-wide ttQiistmem is iised to decrease the Alann Prio^ 



permitting diminfehed Alarm viatality. TAB1£ m describes the AIJ^RMS Attiibule, in detail, as foUows: 



[TTUaMm Attribute; ALA^Spq (N ' 






CV 

(or none) 


(same as LAALM) 


(same as 
LAALM) 


(same as 
LAALM) 


(same as 
LAALM) 


ENAB 


Read: (view) 

Write: (alarm] 

Config: N/A (init TRUE) 


-NO" 
"YES" 


0.0 
1.0 


0 
1 


LAALM 


Read: fview] 
Write: N/A 
Dmfig: N/A 


"OK" 

(alami word of 
Nth alarm) 


0 

(alarm type 

nnmbwofNth 

alarm) 


0 

(alarm type 

immberofNth 

alarm) 


MODULE 


Read:' fview] 
Write: N/A 
Config: N/A 


Module name 
for Nth alarm 
attribute. 


N/A 


N/A 


NALM 


Read: (view] 
Write: N/A 
Config: N/A 


''Na' 
"YES" 


0.0 

1.0 


0 

1 


PR! 


Read: (view). 
Write: N/A 
Config: N/A 


"LOW" 
"MEDIUM" 
"HIGH" 
(priority of Nth 
alarm) 


2.0 
1.0 
0.0 


2 
1 
0 


PRIAD 


Read: [view] 
Write: (alarm) 
Config: N/A (init 0) 




0.0..3.0 


0„3 


TAG 


Read: [view] 
Write: N/A 
Config: N/A 


FuO reference 
path for Nth 
alarm attribute. 


N/A 


N/A 



User-Level Alarm Consolidation is achieved using an "Alarm Barmer^ in the graphical user 
interface. Alarm consolidation is supported for a "current user^. Each user is granted authority over one or 
10 more Plant Areas. The "current user" alarm consolidation provides the abili^ to present the highest priority 
alarms of the set of Plant Areas currently in the user's span of control A preniefined "attribute container" 
exists, named "llflSUSER", which supports the ALARMS[N] Attribute. Users optionally construct displays 
refmndng 1HISUSER/ALARMS[N].ficld* to aUow quick access to the highest priority alarms for the 
**cuiiBntiiser^. 

15 A user Enables aiod Disables Alarms if granted an alarm privilege. With the alarm privilege, a user 

may Enable or Disable a single Alarm Attribute by writing to the £NAB field (e. g. writing TRUE to 
*AREAl/nC101/HIALM£NAB*. Each Alarm Attribute in the process control system inchides a single 
Enable/Disable cottditioa When one user diangesstate» Alarms are Enabled/Disabled fiir all users. With 
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the alann privilege, a user ma^ Enable or Disable all alanns in a SP88 Module Alarm by writing to the 
.ENAB field of the ALARMS Attribute (e.g. writing TOUE to •AREAl/FIClOl/ALARMS.ENAB*)- 
Disablijig Alanns at the Module Icird overrides, but does not overwrite, individnal Alarm's .ENAB 
conditioa Wh^ Alanns are feiaMedM the Module level. Alarm jmKcs^ 
Alarm's £NAB ooiuiitioii is restored 

Each SPSS Module in the system includes a single Enable/Disable condition. When one user 
changes Slate, aU Alanns iti that Modtfle are Enabled/DissOiled for all useis. 

A user having an operate privilege can Acknowledge Alanns. With the operate privilege, a user 
Acknowledges a single Alarm Attribute by writing FALSE to the .NALM field (e,g. writing FALSE to 
*AREA1/F1C101/HIALMNALM'). Attempts U) write TRUE to the NALM are ignored EachAlarai 
AttnT>me in the process control a^fstcm has a sii^JeAckn^ When one user changes state, 

Alanns are Acknowledged for all users. With the operate privilege, a user inayAcknovriedgeaUalanM 
SPSS Module Alann by writing FALSE to the .NALM fidd of the ALARMS Attribute (e.g. writing FALSE 
to •AREAl/FIClOl/ALARMSJ^ALM'), an qpmtion which has substantially the same efifect as writing 
FALSE to the .NALM field of aU Alann Attributes in the Module. Atteiiq)ts to write TOUE to the .NALM 
are ignored 

A user havii^ an alarm privilege can change alarm priority. With the alarm privilege, a user may 
change PRI on a single Alarm Attribme by writing to the .PRIfidd(eLg. writing Oto 
•AREAl/FIClOl/HMLM PRI* to make it a "fflGIT prioriQr alann). Since Auto Acknowledgmmt behavior 
is determined by Alann Priority, changing Alarm Priority may cause an Alarm to change acknowledgment 
status. For exanQ>le, changing from a priority with AutoAck FALSE to a priority %vith AutoAdc TRUE 
should cause nnadaiowledged alanns to be admowlcdge. Also, changing from a priority with AutoAck 
TRUE to a priority with AutoAck FALSE should cause acknowledged alarms to become unacknowledged. 

Each Alarm Attribute in the system has a single .PRI conditioa When one user changes state, JIU 
is changed for all users. 

Witii the alarm privily a user may adjust the efiTectivc priority for aU alanns in a SPSS Module 
Alann by writing to tiie.PRIAD field of the ALARMS Attnl>ute. For cscan^e, a user writing 1 to 
'AREAl/nC10yALARMS.PRL\D* increases the current Alarm Prioriqr value, thereby i«nrin«Ktnc the 
annuciation behavior, by one **stq>" so tiiat fflGH priority becomes MEDIUM priori^, and LOW priwity 
becomesLOG. TTie user only sets PRL\D to positive nurabm and tiierefore is only used to dimin^ 
annundationbehavior. Setting PRIAD to 0 reestablishes the "nonnal'^ priorities dctennincd per Alann 
Attribute. Kfective alann priorities are not adjusted -^elow^ LOG. Since Auto Acknowledgment behavior is 
detennined by Alann Priori^f , changing PRIAD at tiic Module levd may cause individual Alanns to change 
acknowledgment status. 



wo 98/36335 



-73- 



FCr/US98A)lS73 



Bach SI^SModote in tbe system has a sii^e .PRI^ When one user changes state^ all 
Alanns in thai ModolB an affected for all 

Alanns aie viewed nsing a (^lay under a standard FIX^Al^^ The FDC^ graphic 

and display piognun, vMch is maikefed hy InteUution of Norwood, MA, is well known in the conq>uting 
5 am. The FIXT^ Alarm Sunmiary link is the primaiy method to 

Alarms. AUcapabiiitiesof the Alann Sonmiaiy link are supported, with the foUo^^ 
extensions. First, a *Tagnaine''cohnttn shows the process contn>lsy^ 

the Fidd name;, for the Alaim AttxibatB (eg: ^AREAI/FICIOI/HIALRM'). Second, a "^Description*' 

contains a user-configured stdng tfam is construGled at the time the A^^ 
10 o^rtures the value ofup to two Attrilmles at the poim the Alarm was firs^ Only one "Alarm" per 

' Tag^ is possible so that multiple Alarms m^ be shown for each SP88 Module in the Alarm Summary. 

Third, a "lime Last*" entry contains the time of the last state transition for the Active Alarm, which could be 

the time of acknowledgement, or the time of the last transition between Active/Inactive for an 

unacknowledged alasm. Fourth, a 'Tlbde'* column emiy, which shows FDCSCADA Node source f^ 
15 Alarm, is meaningless for jfm>cess control sy^ 

Fifth, alt Alarms are mapped into one of Ihe FIX Alarm types to achieve foreground color based on the 

Alanniype. 

A user can access an Alarm State Transition Joumaling record. Alarm state transitions are recorded 
in the Event Journal assigned to a Plant Area. AH alarm state transitions shown in FIGURE 41 are recorded 
20 in the Event Journal, including transitions between the Inactive/Unadc'd 4114 and the Active/(>nack*d state 
4118. Thus an operator viewing the LAALM field in di^lays or alarm summaries does not see transitions 
b^ween ActivB/Inactrve states for unadknowledged alarms, these transitions am recorded in the Evmt 
JoumaL 

Event journal entries for alarm state transitions indnde: (1) a timestamp of the alarm state transition 
25 as deterinined by the device (e.g. controller) detecting the alarm condition, (2) an "ai^^ 

distiiiguishes from other event journal entries, C3) a user-defined alarm category, (4) a current alarm tmoiitv. 
(5) an alarm word string as configured in the system Alarm Type table, (6) an new alarm state, (7) an 
attribute reference string or path for the alarmed attribute, and (8) a description string assanbled from the 
desciiption string configured in the Alarm l^pc table, with the configured (up to two) Attribute values . 
30 inserted in the string. 

A Evm Joonsal browser plication presents data in a manner shown in TABLE ly, generally 
sorted by timestamp and filtered on event type = "ALARM" and attribute reference string = 
"HClOl/PIDl/HIALNr): 

TABLE IV 



DA-MO-YR 


ALAR 


PROC 


MEDI 


HIG 


ACT/UNA 


FICIOI/PIDDHI 


vahie96.2 


10:11:04.4 


M 


ESS 


UM 


H 


CK 


ALM 


limit 95.0 
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DA440-YR 
10:11:18.6 


ALAR 
M 


PROC 
ESS 


^4EDI 
UM 


me 

H 


INACT/UN 
ACK 


FIClOl/PIDl/HI 
ALM 


value 93.7 
liinit 95.0 


DA-MO-YR 
10:13:45.6 


ALAR 
M 


PROC 
ESS 


MEDI 
UM 


HIG 
H 


DISABLE 
D 


ncioiypiDi/Hi 

ALM 


value 93.1 
limit 95.0 


DA-MOYR 
10:22:00.1 


ALAR 
M 


PROC 
ESS 


MED] 
UM 


HIG 
H 


ACTAJNA 
CK 


FIClOl/PIDl/HI 
ALM 


value 95.8 
limit 95.0 


DA-MO-YR 

10:22:20.9 


ALAR 
M 


PROC 
ESS 


MEDI 
UM 


HIG 
H 


ACT/ACK 


FIClOl/PIDl/HI 
ALM 


value 95.9 
limit 95.0 


DA-MOYR 
10:27:59.4 


ALAR 
M 


PROC 
ESS 


MEDI 
UM 


mo 

H 


CLEAR 


ncioi/pmi/m 

ALM 


value 94.0 
limit 95.0 



Alann state transitiaiis . events in the Bveitt Jounial aie distill 
althoagh operator changes cause conespoiidtng alaim state ciiaoges. For exan^te; as shown in TABLE V as 
follows: . 



DA-MO-YR 
10:13:45.9 


CHAN 
GE 


CJON 
ES 


A 




FTC10I/PID1/HL\LM. 
ENAB 


new value = 
FALSE 


DA-MO-YR 
10:22:00.1 


CHAN 
GE 


CJON 

ES 


A 




HClOl/PIDl/fflALM. 
ENAB 


new value* TRUE 


DA-MO-YR 
10:22:21.3 


CHAN 
GE 


aoN 

ES 


A 




nClOl/PIDlOTALM. 
NALM 


ALARM/ACK 


DA-MO-YR 
15:28:59.4 


CHAN 
GE 


BSMI 
TH 


A 




HCIOLENAB 


new value = 
FALSE 



The Alann Amibutes axe configured, thereby setting the Alann behavior and piesentation, using the 
described sequence of operations. Fiist, an ^'Alazmiypes** Table and an "Alann Annundatian** Table axe 
configured. Second, in an optional step, the user-defined alarm conditions are configured, setting the 
boolean Attributes. Third, Alarm Attributes are created to reference the boolean Attrilnites, thereby 
identifying the System "Alarm T^pe", priority, and the like. Fourth, Module "instances" are created based on 
Module D^uiitions that contain Alarms. Fifth, a presentation of Alarm information is inseited into displays 
^ictuies) via database links, ^mamic color links, and Alarm Summary links. Sixth, the "Alarm lopes'' and 
**Alarm Annundation" Tables axe confignicd. 

The Alarm Type" table has several functions, including (1) acting as a system (Site) wide common 
resource which defines a common Alarm presentation behavior to speed the Alarm configuration process for 
each Alarm. Q.) encouraging standard alaim messaging in Snmmarics and History Journals to improve qoeiy 
and analysis that infoimation, (3) mapping alarms into FIX Alarm States. 

The ''Alarm Types" Table ccmtains o^umns including an Alarm Type, an Alarm Word, a categoiy 
and a description string colnmn. The Alarm Type colnmn contains a brief desccq)tion of the Alarm 
which is used to sdect the qtpropriatel^pe when creating an Alarm Attribute. The Alarm Word column 
inchides a string that is retomed when reading the A.CUALM or A JLAALM Fields whoi the Alarm is 
Active. The categoiy cdumn describes a user defined word recorded in the Event Journal used to help 
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filtd/soitquenes. The description string appears in the Alann SQim^^ 
holders for Attiilmte value substitution at Alarm Detection time. 

The **Alann lypes^ Table de&uU content is shown in TABLE VI as follows: 



TABLE VI 




NEW 



ANY 



CFN 



COS 



HIHI 



LOLO 



RATE 



HIGH 



LOW 



DEV 



OK 



i (oser defined) 



I (user defined) 



SYSTEM 



SYSTEM 



PROCESS 



PROCESS 



PROCESS 



PROCESS 



PROCESS 



PROCESS 



PROCESS 



PROCESS 



- v>iA>\y*«r^/.^',v.x.;.-.v,v.: 

illiiiii 



Statistical Alann Type %PI 

Value %P2 



New Alarm Value %P1 



Any Alarm Value %P1 



Change From Nonnal Value %P1 



Change of State 



miiiii 



High High Alarm Vahie %P1 
Limit %P2 



Low Low Alarm Value %P1 
Limit %P2 



Rate of Change Rate %P1 Limit 
%P2 



High Alarm Vahie %P1 Limit 
%P2 



Low Alarm Value %P1 Limit 
%P2 



Deviation Alarm Target %P1 
Actual %P2 



Normal State 



(user defined) 



5 Standard alann types match the alarms 9pessiq>ported in FDC^ 

The "Alann Annrntciatian** taMe is a system (Site) wide common resmuce which fbniishes a 
common definition of Alann annundationbduivior to qwed the Alarm configuration process for each 
Alarm. 

The "Alarm Types** Table contains the ccdumns including an Alarm Priority, an Auto 
10 Aclmowiedgement, a WAV file and a PC speaker frequency cohmm. The Alarm Priori^ designates the 

Alarm pdoihy word 0nGH(MEDIUM/LOW/LOG). The Anlo Acknowledgment cohmm contains a YESfNO 



^ FrbbaUy no reason for this to be Gonfigmed, or even lisOile to the 
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value indicating if alanns of this priority should be automatically admowledged when detected andproviding 
an oppononity to make less impoitantalanm less ''distiactm Hie WAV file contains a filename of a NT 
compattble .WAV file iWiidi is played 0ooping) when an Alann is detected (within the scope of the cunent 
nseOata Woricstation with a sound card. Omitting this file name indicates that no .WAV file shmild be 
plaiyed for alanns with this priority. The PC Speaker frequency sets a vahie used to play a tone on the PC 
q^eakerwhenan Alarm is Elected, within the scope ofthe current user, at a Woricstation without a sound 
card. A value of 0 indicates that the PC speaker should not be used for alarms with this prioriQr. If a .WAV 
file and a non 0 speaker frequency are specified for the same alarm priority, the PC q>eaker is used only if no 
sound card is ]wesent 

The **Alarm Annunciation" Table de&ult content is shown in TABLE VQ as follows: 



TABLE VU 




A user attaches Alarm (behavior) to boolean Attributes by creatiiig Alarm Attributes according to 
the SP88 Module Definition which reference another boolean Attribute in the same Module. 

A user create an Alarm Attribute by entering: (I) atarget Attribute by path or tv^ drag-and-drop, for 
exanqde, (2) aboolean Attribute defining the alarm condition, (3) an Alarm Type selected fiom the system- 
wide list of Alarm Types, (4) an Alann Priority (High/Medium/Lxrw/Log), (5) an Initial Alarm Enable 
condiUon (YES/NO), (6) an Invert Input (YES/NO), (7) an optional Name of Attribute having avaluetobe 
substituted for %P1, (S) an optional Name of Attribute having a value to be substituted for %P2. 

Items 7 & 8, the Attribute names; are restricted to Attributes in the same SP88 Module and are 
specified as ^'module relatrve** attribute references (e.g. "SF* and "PIDl/PV ratha than "FICIOI/SP" or 

"ncioiypiDi/pv. 

The user also creates Module "instances" based on Module Definitin^^y that ^t^ip Aia""< When 
a Module instance is created, all Alarm behavior specified in the Module Definition applies to the Module 
instance, llie JW and .ENAB fields may be oveiridden on AlannM Attributes 
cre^ For example, iffor an Alarm Attribute named *mC»ILIM^ 

Module Definition is constructed, then vAuoi the Module instance is created, 'HI(9ILIMITED J*RI' may be 
ovenidden to be LOW for this instance. 

Alarms are supported for Device/Siibsystem Attributes in ControlletSL Attributes are defined for 
devices and device sid>5ystems to provide access to information about the operation of the control system and 
connections to other systems. The Attributes are accessil^ via diagnostic tools and via pre-defined or user- 
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defined displays. It is valuable for some of these Attributes, especially "consolidation" Attributes, to 
participate in the Alaim system to draw attention to abnonnal conditions in the control ^em. 

Users oeate Control Modules (instances) to implement a desiied "Device Alann" strategy for 
Controllers and Subsystems, including processor, communications, I/O, redundancy, and the like. 

Using Function Block algorithms, the Device/Subsystem Attributes are accessed most efficiently in 
the same device, torn also sqipoitod for other Contrdleis and Woi^ Device and Snhsyston 
Attributes are used as iiqmts to Rmction BlocksL whidi then can be confignmd tn applying aiam limUy 
these Attributes, comreiting these values to boolean Attributes. AlannAttributes then reieience the boolean 
Attributes. In general, the fonalgoritlmidefiiutionc^biUty of the Fto^ 
simple or conq)lex I>evicc Alaiming schemes. 

A number of the pr^-defined AlannlVpesE, iK^iich are consistent with FDC^m alann types, are 
smtaUe for distinguishing 'l>evice Alarm'' presentation and behavior. Pre-defined Control Module 
Definitions are siq)plied providing fairly comprehensive Device Alarm '^modules'* for Controllers, and each 
type of I/O system. Usm optionally disable or extend these standard modules. 

Users may elect several sirat^ies for placing Device Alarm modules in Plant Areas including a 
small*system strategy, a "segr^tion* ^t^ and a^partitioned reqjonsibility" strategy, for example. In the 
small system an "all in one" strategy is inqrased in which the Want Area concept is not applied. One or 
more Device Alarm Modules in each Controller form an integrated presentation of Device and SP88 Module 
alarms. In the segregation strategy a separate Plant Area is designated which has all Device Alarm modules 
from all Controllers, The segregation strategy enables Area filtering/sorting on Alarm summaries, allowing 
Operators to focus on SP88 Module Alarms and Process/Maintenance Engineers to focus on Device Alarms. 
Hie partitioned tesponsibiH^ strategy is used when the system becomes large enough to control scope of 
responsibili^ by Plant Area. Device Alarm Modules are placed in the same Plant Area as the SP88 modules 
impacted by the Device Alarm Modules. The partitioned responsibility strategy forms an integrated 
presentation of Device and SP88 Module alarms for Plant Areas within scope of responsfinlity. 

Alarms are siqipoited for Devioe/Sid>S3^stemAttnl^^ User-initiated applications 

such as Draw, View, engineering tools, and die like individually present information about abnormal 
conditions enors encountered, in the ^ropriate context Workstation Services whidi are activated on a 
workstation before a user logs on and continue to run through log-oflG1og«on cydes) in^lemM a technique 
for drawing attention to problems, even for an unattended Worksiatioa In one embodiment, Woricstation 
Services arc monitored by Device Alarm Modules executing in one or more Controllers. The Services 
construct a set of status and integrity Attributes, which are accessed by Cbntroller(s) rutming instances of 
Device Alarm Modules which control the user-4e&ned Device Alarming strategy. Pre-defimed Control 
Module Definitions are si^qptiedprovidiiigfoirfyconqirehensi Workstations, 
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and each majOT Sendee (c.g.co!niinii^ Useremaydis^eorcxlcncilbese 
standanl modules. 

In one eiiri)odiiiient of theimKxss Gontid syst^ 
status are given a priority of "UXr. IXKl^ Alanns are nm consolidatBd in ALAIUVl^ 
appear in the Alann Summaiy. do not provide audible annunciation of state changes, and ^pearin Ev^t 
Journals as t30pe''EVENT" rather than type «AL^^ In other respects a LOG priority Alarm operates as 
HIGH/MEDIUM/LOW priority Alarm so that an event (1) is enabled/disabled individiMlly. (2) is disabled at 
the Module level with other alanns, (3) indhidual Alarms can be 'tened into Events^ by dianging their 
priority to XOG" (writing 3 to J^. 

By setting PRIAD at the Module level, one or more levds of Alarms can be converted to Events 
(e.g. writing 2 to .PRIAD drc^s all Alarm priorities in the Module by 2 steps; HIGH priority becomes LOW, 
MEDIUMandLOWprioritybecomeLOG,LC)GremainsLOG). Setting .PWAD to 3 forces afl Alarms in 
the Module to become «Evcnts•^ CU ALH L AALM. NALM field supported to display commt status (even 
blinldng if unacked). 

LOG events also (4) may invert the input boolean, to reverse the sense of the OK event condition for 
usage to log changes in state of Discrete Iiqwts, (5) may add user defined "alarm words" to the Alarm Types 
tabic to give event conditions useful namds, (6) record all stale changes for a LOG priority alarm in the Event 
Journal. 

User selectable "intensities" of syston event detection (e.g. "debug intensity^, "normal intesity*', 
"shutdown inlenaty") are configured in Control Module algorithms based on the setting of a user defined 
''intensity" Attribute. System Events arc thus aligned with one (or perhaps more) Plant Areas, and so 
enabling the Event Journal on a Worlcstation for one or more Plant Areas automatical^ sets the destination 
for all "System Event* records. 

A user changing an Attribute or invoking a method on a Systan Object is considered an event and 
is recorded in the apprqjriate Event JoumaL Changes to control hierarchy (Control Module, Equipment 
Module, Plant Area, etc.) Attributes are recorded in the Event Jomnal(s) designated for that Plant Area. 
Changes to Device/Subsystem Attributes are recorded in the Event J6umal(s) for the '"primary Plant Area" 
designated for that Device. 

Refening to nGURE 42, a context diagram shows a context for definiAg an alarm event with 
req)ect to a control module. An Alann aHiears in a "Tlant Area scope" active alarm list presenta A 
composite module (CM) instance 4210 indodes a PID limction Uock 4212, an oui|Nit attribute 4214 and a 
high alarm attribute 4216. A user, such as a configuration engineer, selects the ciniqxiate mod^ 
editing and selects "add alarm" 4220 on Attribute "HMI-. The user also sdecis the evott priority d^nition 
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named ''Advisoiy^ 4m and the cnrent type defiidti^^ The user then saves the 

changes to the conuol module 4210. 

Ilefisning again to FIGURE 40, alann and event managemem is desc^ 
defined ''events^ which are configured as LOG |Nrioii^ Alanns introduce nmhiple behaviois into the process 
contnil systent 

A qwdal kind of RtAtlnbote* hereafter called lUAlan^ 
supporting Alann specific fields such as CUALH^^AIAi^ Read 
access to the fidds allows presentation of the state (tfindhddual Alarms Write access to selected fields gives 
an abifi^ to Aclmowiedge Alanns; and diaiige certain alarm 

Several charactoistics of Alarm bdiavior, such as Disd>]ed and AUTO AdC behavior, may be 
overridden on-line at the SP88 Module level Rcveiting to the individual Alann conditions of 
End>Ied^[)isabled and NoAutoAcfc/AutoAck occurs when the Mo^ The 
changing of Module level ovenides should ''immediately^ iny>act individual Alann states. Thus changes on 
the Module level ovande force re-evaluatum of all Alann states within the module under the new conditions. 

Active alanns are consolidated at the Module (RtModule 4030), Plant Area (RiPlantArea 4010), and 
User Session so that the ''highest priori^ alarms" at each of the levels may be presented. This consolidation 
is accessed through the ALARMSQ Attribute suf^rted by Module, Plant Area and User Session objects. 

FDCTM Alarm Summaiy Ltiiks are used in FDC™ pictures (displays) to present a list of "cunent** 
alarms. The cmitent for the Alarm SunmiaiyUidc is maintained by the ALMSIJM.E>^ 
down when FIX™ shuts down, and FDC^ shutsdownwheneveranNTuser logs ofi^, and NT usees log off 
to allow a new user to *'lag in**.) Thus the system must both ''prime*' the ALMSUM process with all current 
alanns (subject to current user responsibility scope) to get it started when an new user lo^-on, and it must 
feed the ALMSUM process information about new alarm occnnenoes, and alam acknoidedgments so a i^h 
to-date summaiy can be presented. 

All alarm state transitions are directed to the appropriate Event Joumal(s) (RtEvcntJounial 4020) for 
the Plant Area which ''amtains^ the RtAlannAttiibute 4034. Mult^le Event Jonmal taigets are supported, 
so that a complete Event Jounial can be reconstracted if one workstation ronning one of the Event Journals is 
off line for a period of time. 

Audible annunciation ci Alarm endy state transitions executes on workstations doing Alarm 
Summarizatimi (feeding the FIX ALMSUMJSXE process). Audible annunciation may consist of a 
continuous tone (user configured fiequency) on the PC speaker^ and/or a continuous (looping) .WAV file 
piston a Gonq»atibie sound card installed in the PC. A program is executed to turn offbolh the speaker 
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aiul the «md card, thus the soimd may be tumcrf off 
IGON in the program Gniiq> if FIX VIEW is not nuut^ 

Referring to FIGURE 43, an oi^ commonicaaon diagram illustrates a method for perfonning an 
attrilrote write operation that evokes an ''in alatm** status. 

Previous to the attribute write operation, a RtAlannAttribute has been configuied and installed, 
alarms aic ENABLED at both the Attiftnte and the Modrf 

Attribute and the Module level, and the cnrcent Alarm state is '^btacttve/Acknovrfedged". 

The *VriieAitribme'*m«hod causes the state of an AlannAttrilnrte The 
aiann fields of the Alann Attribute are updated to reflect the new Alarm state. An event occurrence record is 
constructed, and sent to the Module. Plant Area, and woricstation applicatiOTS (Alarm Summary, Event 
Journal), as needed. 

When the attribute write op^ation is con^lete, the current Alarm state is 
"Activc/Unac^mowlediged•^ the acthre alarm has been recorded by the Mo^ 

has been constructed, and has been queued for transmission to devices monitoring this Plant Area in this 
Device. 

In a stqj 4310 of the write attribute method, RtAlaimAttribute receives a writeAttiibute, which 
causes a state transition in the boolean Attribute to enter the alarm stale. In step 4312, RtAlaimAttribute 
gets alannDisable stams from the RtModuIe containing RtAlarmAttribute so that both Attribute and 
Module Alarm behavior are ENABLED. In step 4314, RtAlannAttribute gets alarmAutoack status from 
the RtModnle containing RtAlannAttrilmte so that for both Attribute and is 
DISABI£D. In stq> 4316, RtAlaimAttribute conqnites a new alann states the 

state and reads the prototype event descriptor string from RtEventTypcBellnition using Alarmiype as an 
index. In step 4318, RtAlarmAttribute constmcts the descriptionStiirig for the RIEventdccurenceRecord, 
reading current attribute values from the iu>ntaining RtModuIe, if necessary. In step 4320, 
RtAlaimAttribute constructs a new RtEvoitOccnrenceRecord. Since a new alarm is created, 
RtAlarmAttribute tells its containing RtModuIe to addErentOcc^rrence in step 4322. In step 4324, 
RtModnle tells its RtActiveAlarmlist to addEventOccnrrcnce, adding a new entry to the list and 
returning a handle by which the entry can be accessed in the liilmeL This handle is ultimately stored by 
RtAlannAttribute. In stqp 4326. RtModnle sends the RtBventOccurenceRecord to the RtPlantArea of 
RtModuIe via recordEventOccurrcBce. In stq> 4328, RtPlantArea tdls its RtAreaEventLog to addEvent, 
RtAreaEyentLog sees that at least one workstation dimt has r^crcd an intoest in receiving EventLog 
records, creates an Rt£vcntix>gRecord from the RtErcntCkiwcnceRecord, and queues^ 
RtEventLogRecord, thereby destroying the RtEventOccnrenceRecord. 
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Also Inferring to FIGURE 43, the object oonununication diagram is also ^licable to 
Acknowledgement of an Alami, causing the cnrrau alann state to go to *'Active/Ackno\iiedged". The new 
alann state for the existing alann is recorded by the Module, a new event occunence record is constructed, 
V and is been queued fotnoisnussion to devices inonitoring this Hant Area in ^ Themethod 
indndes application of the "Sviite Attribnt^ method (writing FALSE to the N ALM Fidd) to cause the state 
of an Alarm Attribute to be acknowledged. Alarm fields of the Alarm Attribute are updated to reflect the 
new Alarm state. An cvcat oocurreniDe record is constructed, and seiit to this Modnl^^ Pia«f Area, and 
wodcstation a|q>lications (Alarm Snnmiaiy, Evem JouniaO as n^^ 

In stq> 4310, RtAlarmAtdibnte receives a writeAltribate, caosing the NALM Field to change state 
to FAUE. In step 4312, RtAlarmAttiribnte gets alarrnDisaU^ RtModole containiiig 

RtAlainiAftiibute so that both Attribute and Modute Alarm bdiavior are ENABLE Instq»4316, 
RtAlannAttrfhote conqrates a new alarm state, the ** ActiveAJnacknowledged** state and reads the prototype 
event desoiptor string firom RtEventTypeDefinition using Aiarmiype as an index. In step 4318, 
RtAlarmAttrihute constructs the descrq>tionString for the RtEventOccnrenceRecord, reading current 
attribute values from the containing RtModuie, if necessary. In step 4320, RtAlannAttribttte constructs a 
new RtEventOccnrcnceRecord. Since an existing alarm is updated, RtAlarmAttribute tells the RtModuie 
containing RlAlarmAttribnte lo updateEventOccurrence, identi^ring RtModuie by the handle returned 
when fimn updateEventOccunnence in sup 4322. In stq> 4324, RtModuie tells RtActiveAlarmlist to 
updateEyentOccnrrence, thetdyy updating the existirig entry in the list In step 4326, RtModuie sends the 
RtEventOccurenceRecord to the RtnantArea of RtModnle via rccordEYentOccnrrence. In step 4328, 
RtPlantArca tells its RtAreaEventLog to addEvent, RtAreaEventLog sees that at least one workstation 
cli^ has registered an interest in receiving EventLog records, creates an RtEveutLogRecord from the 
RtEventOccuraiceRecord, and queues the RtEventLogRecord; thereby destroying the 
RtEventOccurenceRecord. 

Also referring to FIGURE 43, the object communication diagram is also applicable to 
aknowledgement of clearing of an alarm condition, in which the 'Svrite Attribute" method causes the state of 
an Alarm Attribute to go out of the alarm state. The alarm fields of the Alarm Attribute are updated to reflect 
the new Alarm state and an eveiu occunence record is constructed and sent to the Module, Plant Area, and 
ixtukstationaiqxtications (Alarm Summary, EvemJouni^ When the write Attribute method is 

oon^lete, the curiem Alann state is ''Inaclive/Acimowle^ The cunem alarm information for this alarm 
has been removed by the Module. A new event occunence record has been constructed and queued for 
transmission to devices monitoring this Plant Area in this Device. 

In step 4310, RtAlarmAttribute receives a writeAttribute, vrtiich causes a state transition in the 
boolean Atnamte to go out of the alarm state. In step 4312, RtAIaimAttribute gets alarmDisable status from 
the RtModuie containing RtAlarmAttribute so that both Attnbote and Module Alarm behavior are 
ENABLED. In step 4316, RtAlarnAttrOnite computes a new alarm state, the ^'Active/Unadcnowledged^ 
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stale and reads the prototype event descriptor string from RtEventTypeDeGniUon using AlannXypc as an 
index. Instq>43]S,IttAlansAltrilratecQnstnictsthedesaq^ 
leadtng current attribute values from the ccmtaining RtModule, if necessary. In step 4320, 
RtAlannAttrlbnte oonstmcts a new RtEventOccurenceRecord. Since an existing alaim is deared, 
RtAlannAttribnte tells the RtModole containing RtAlannAttribute to updateEventOocurraice, 
identifyii^RiModiitetiy the handle Tetnmedvdie^ In stq) 4322, RtModnle 

tdls RtActiveAIarmlist to updateEvenlOccurrace, thereby iqxlating the existing cntiy in the list In stqi 
4326, RtModule sends the RtEventOccurenceRecord io the RtPiantArea of RtModnle via 
recordfiventOccnrrence. In sicp 4328, RtPiantArea tdls its RiAreaEvenlLog to addEvent, 
RlAreaEvemLog sees that at least one woikstation ciicnt has registered an interest in receiving EventLog 
recoids, creates an RtEventLogRecord fiixm the RtEventOccnrenceRecord, and queues the 
Rt£veatl4)0Ucord, thereby destroying the RtEventOccurenceRecord. 

Also lefming to FIGURE 43, the object communication diagram is also applicable to disablemrat 
of an alarm by causing the ENAB Field of an Alarm Attribute to become FALSE. The alarm fields of the 
Alann Attribute axe updated to reflect the new Alarm state and an cvem occurrence record is constructed, 
and sent to the Module Plant Area, and woikstation applications (Alarm Summary, Event Journal), as 
needed Follovringthedisablememof an alarm, the cunem Alarm state is ''Ina^ 
ENAB field is FALSE. The currem alarm information for this alaim has be^ removed by the Kfodu^ A 
new event occurrence record (alarm DISABLE) has been constructed and is quei^ for transmission to 
devices monitoring this Plant Area in this Device. 

In step 4310, RtAlarmAtfribirte rec^ves a writeAttribute, which causes the ENAB Field to 
become FALSE In step 4316, RtAIanuAttribute computes a new alarm state, the 
"Active/Unacknowledgcd" state and reads the prototype event descriptor string from RtEventTypeDefinition 
using AlarmType as an index In st^ 4318, RCAlannAttribute constructs the descriptionString for the 
RtEvoitOccurenceRecord, reading current attribute vahics from the containing RtModule, if necessary. In 
step 4320, RlAlarmAttributc constructs a new RtEventOccurenceRecord, identifying this evem as an 
alarm disable event Since the alarm is disabled when previously active, this cvoit is the clearing of an 
existing alarm, RfAiarmAttrilHite tells the RtModule containing RtAIanuAttribute to 
dear^ventOccnrreDce, idoitifying RtModule by the handle relumed when from clearEvaUOccurraice. 
In st^ 4322, RIModnle teils RCActiveAlarmlist to clearEventOccarraace, therdvy namndiig the existir^ 
entry firan the list Instep 4326, RtModule sends the RtEventOccurenceRecord to the RtPiantArea of 
RtModule via recordEventOccurrence. In step 4328, RtPiantArea tdls its RtAreaEvenOog to addEvent, 
RtAreaEventLog sees that at least one workstation cliait has registoed an interest in receiving EventLog 
records, creates an RtEventLogRecord from the RtEventOccur^ceRccord, and quoies the 
RtEventLogRecord, thmby destroying the RtEveatOcenrenceReconL 



W09M6335 



-83- 



PCmJS9mi573 



Also lefening to FIGURE 43, the object commmiicatioii diagram is also applicable to enablement 
of an alann by causing the ENAB Reld of an Alann Attribute to become TRUE Prior to enablement of an 
alaim, the ainem state ofthe boolean Attnlmte shows the alamw^ AutoAckis 
False at the Attribute and Module level. Thealaimfields^^the Alann Attribute axe updated to reflect the 
. new Alaim state and an event occunenceiecord is constracted, and seiit to the Mo^ 
. ivoifcstation applications (AlamSummaiy^ Following the disablement of an 

alaim, the cinientAlam state is **Active/Uoad^ Thecunent 
alann infonnation for this alarm is stored by the Module. A new event occunenceiecoxd (alarm 
Active/Unacknowledged) has been constrocted and is queued for transmission to devices monitoring this 
Plant Area in this Device. 

In stq> 4310, RCAlarmAftribute receives a writeAttribute, which causes the ENAB Field to 
become TRUE. In step 4312, RtAlarmAttribute gets alarmDisable status fitom the RtModule containing 
RlAlannAttribute so that both Attribute and Module Alarm behavior are ENABLED. In step 4314, 
RtAlarmAttribute gets alarmAutoadc st^ from the RtModule containing RtAJarmAttribnte so that for 
both Attribute and Module Alarm AUTOACK is DISABLED. In step 4316, RtAlarmAttribute computes a 
new alarm state, the Actrve^Unadouraiedged" state and reads the prototype event descriptor string from 
RtEvcaH^eDcflnition using Alarml^pe as an index. In stqi 4318, RtAIarmAttribttte oonstnicts the 
deso^tionString for the RtEventOccnrenceRecord, reading current attribute vahies fiom the containing 
RtModule, if necessaiy. In Oep 4320, RtAIannAttribnte constructs a new RtEventOccurenceRecord. 
Since the alarm is new, RtAlarmAttribute tells the RtModule containing RtAlarmAttribute to 
addEventOccnrrence, identifying RtModule by the handle returned when from addEventOccurrence. In 
stq) 4322, RtModule tells RtAcriveAlarmList to addEventOccurrence, thereby adding a new cntiy to the 
list In step 4326, RtModule sends the RtEventOccurenceRecord to the RtPlantArea of RtModule via 
recordEventOccnrrencc. In step 4328, RtPlantArea tells its RtAreaEventLog to addEvent, 
- RtAreaEventLog sees that at least one woricstation client has registered an interest in receiving EventLog 
records, creates an RtEvcntLoglReconl fiom the RtEventOcGiunenceRecord, and queues tiie 
RtEventLogRecord, there^ destroying the RtEventOccnrenceRecord. 

While the invention has been described with reference to various embodiments^ it will be undemood 
that these embodiments are illustrative and th^ Many 
: variations, modification^ addttions and inqmivements of the embodiments described aie possible. 
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WE CLAIM; 



1 1. A process contfol system (100) for controUing a plurality of field devices of multiple different 

2 field device types induding smait-type field devices (132) and non-snuut-Qpe field devices (136), the process 

3 control system conqmstng: 

4 a plurality of distributed controlleis (1 10) coupled to the field devices; and 

5 a software scystem inchidiiig a phnality of control modules (440) sdectivelfr installable and operative 

6 on ones ctfthe phirality of distributed controllcfs. the software system for otnimiinf raiing 

7 with the smart-^pe and the non-sniait4ype fidd devices and for controlling the smart-type 

8 and the non-smart-^ field devices. 

1 2. A process control system according to Claim 1 wherein the software system further indudes: 

2 a configuration program for configuring the control modules and installing the control modules on 

3 * the phirality of distiibuted controUos, the distributed controllers retaining the configuration 

4 until reconfigured. 

1 3. A process control system according to (:hdmlwfacn»n the plur^ 

2 configured into a communication services hierarchy including: 

3 a remote object communications (ROC) level for communicating messages between two control 

4 modules in a same controller and between two control modules in difieient controllers, and 

5 a low Icvd conmmnicattons level for inteifedng with communications hardware and transmitting 

6 messages across the communications hardware. 



1 4. A process control system (100) for controlling a plurality of field devices of multiple diffmnt 

2 fidd device types inchiding smait-^ fidd devices (132) and non-smart-Qfpe fidd devices (136), the process 

3 control system comprising: 

4 a plurality of distributed controllers (110) coupled to the field devices; and 

5 a plurality of control means selectively installable and operative on ones of the plurality of 

6 distributed controllers fof, in combination, controlling the smart-type and the non--smart- 

7 type fidd devices. 

1 5. A process control system (100) comprising: 

2 a plurality of fidd devices of multiple different field device types induding smart-type field devices 

3 (132) and non-sman-type fidd devices (136); 

4 a plurality of distributed controllers (1 10) co\sp\cd to the fidd devices; 

5 a workstation (102) coupled to the distributed controllers; and 
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a pliuafitjr of conlnrf means selective 
distiitertcd contidkis for, ^ 
Qrpe field devices. 

6. AoonyRtterpnignimptodactcoiiqiriang: 

a con^iiiBr nsable medinm having coniputable readable code cndxMlied therein indwiiqg a pxoccss 
ccmttol software system controliing a phualitjr of fidd d^ioes of mtiltqpte ^cra^ field 
device t^ses indudiAg smart-type fidd devices (132) and nonrsmait-type field devices 
(136), the i^occss control system (100) including a plurality of distdboted oontnilleis (110) 
coupled to the field devices, the executable program code including: 
a software system induding a phiiaUty of control modules (440) selectively installable and 

dperaitivcanonesofthepluxafi^ctf'distiibmiMlcont^ - 
a oommonication and control tontine for commmiicating with the smact4ype and the non- 

smait^type fidd devices and for contndling fiie smait-^ and the inon-smait-Qiie 

fidd devices. 

7. A computer program product accoiding to Claim 6, the executable program code fimher 
conopiising: 

a user intei^ (300) for intedadng with a user, wherein: 

the smart^ype and the noa-sinart4ype fidd devices 

ardiitectttre standards and the software system performs smart-^ control operations and 
non-smart-'type cmitrol operations transparent to the user over the user inter&ce. 

8. A computer program piodua according to Claim 6 wherein the software system performs smart- 
type control operations using the phuality of control m»dules distributed on the plurality of distr&utcd 
controllers q)eradr^ on the smartHype fidd devices and non-smart-type operations operating on the non- 
sniart-^^ fieM devices independently, sinraltaneottsly and i^ 

9. A computer ^ogram product according to Claim 6 wherein the softwiare system further indudes: 
a configuration program for configuring the control modules and installing tire amttol modides on 

the idmaUty of distributed controllers, the distributed controUcrs retaining fiie configuration 
until reconfigured. 

10. A oomputCT program pnidua according to Qaim 6 wheieiii the phiraK^ 
configured into a comnmnicatLon services hjemeliy ingtiniii^g* * 

a remote olgect comnmnicaticMis (JROQ tevd for conmiunicatiQg messages between two cvmirol 

modules in a same controller ai^ between two control modules in difierent contiolleis, and 

a low level commomcaiions Icvd for interfacing with communications hardware and transmittiiig 
messages across the communtcatiQns hardware. 
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1 1 1. A process oontrd system (100) for controlling a plurality of field devices of nnilti^le diffoent 

2 field device types induifing standant-pratocol field devices (6) and non-standard-protocol fidd devices (12X 

3 the process control syston comprising: 

4 a phualit/ of distributed controllers (1 10) coupled to the field devices; and 

5 a software system indiiding a plurality of function blocks (522) defined in a standard protocol, the 

6 iuncti(m blodcs being selectively installable and operative on ones of the plurality of 

7 distribned oontioUefs fin sdectively controlling a standard-protocol field devke and a non- 

8 standaid-piotoool fidd device. 

1 12. A process control system (100) for controUtng a pluialiQr of field de^ 

2 field device types inchiding standard-prDtocol fidd devices (6) and non-standard-protocol field devices (12), 

3 the process control system oonq>rising: 

4 a phualily of distributed controllers (1 10) coiq>]ed to the field devices; and 

5 a phualiQr of coittnd means selectrvely installable and operative on ones of the plurality of 

6 distributed controllers contrdling, in combination, the standard-protocol fidd devices and 

7 the non-standard^protocol field devices. 

1 13. A process omtrol system (100) comprising: 

2 a phtraliQr of fidd devices of multiple diflTereni fidd device types inciudiiig standard^rotoccd fidd 

3 devices (6) and non-standard-protocol field devices (12); 

4 a phualiryc^distribuledcoiurollefs (110) coupled to the fidd devices; 

5 a workstation ( 102) coiqiled to the distributed conlrollers; and 

6 a software system induding a plmaUty of function blodcs (522) defined in a standard pro 

7 function blodcs being sdectivdy installable and operative on ones of the phirality of 

8 distributed controllers for sdectivdy controlling a standard-protocol fidd device and a non- 

9 standard-protocol field device. 

1 14. A process control system (100) fiar controlling a plurality of fidd devices of multiple difierent 

2 fidd device types induding standard-protocd fidd devices (6) and nonrstandard-piotocol fidd devices (12), 

3 the process control system con^prising: 

4 a phuali^ of distributed contrdlers (1 1 0) coupled to the fidd devices; and 

5 a software system indnding a phiiatity of fimction blodcs (522) defined in a standard piotocd, the 
^ fiinctionl^ocks being selectrvdy(fefinabk,ci^ 

7 contrd module that is operative on ones of the plurality of distributed controllers for 

8 sdectivdy controlling a standard-protocol fidd device and a nnw-fH ^iy fard^protocol Sicid 

9 device. 
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1 15. A piocess control system (100) cQinprisiiig: 

2 aphiiaUiyoffielditeWcesofiiudtiplediffarei&tfiddd^ field 

3 devices (6) and non-standard-protocol field devices (12); 

4 a plurality of distributed controllers (110) coopled to the fidd devices; 
5- . a woikstation (102) coupled to the distributed controllers; and 

6 a software system inclnding a plurality of fimcdon blocics (522) d^ned in a standard protocol, the 

7 function blocks being selectively definable^ creatable, modifiable, and installable as a 

8 control module that is operative on ones of the plurality of distributed controUeis for 

9 selectively comndli^g a standaid-protocol fidd device and a non-standard-protocol field 
10 device. 

1 16. A process control system (100) for controlling a plurality of fidd devices of multiple diffeient 

2 field device types including standard-protocol fidd devices (6) and non-standard-protocol fidd devices ( 1 2), 

3 the process control system comprising: 

.4 a plurality of distributed controlleis (110) coupled to the fidd devices; and 

5 a plordity of contnd moddes (440) selectivcty definable, cieataUe, nKklifisrtsie, ^ 

6 operative on ones of the plurality of distributed controllers controlling, in combination, the 

7 standard-protocol fidd devices and the non-standard-protocol field devices. 

1 17. A process control system according to any of Claims 1 1, 12, 13, 14, 15 and 16 finther 

2 comprising: 

3 a user interface (300) for interfacing with a user, wherdn: 

4 the standard-protocol fidd devices and the non-standard-protocol fidd devices operate in 

5 .. conq)liance with the ddBnedFieldbusardutecture standard and the soft^^ 

6' pexfinms Standard-protocol oontrd operations on standard-protocd field devices and non- 

7 standard-protocxil field devices tran^arent to theuser over the user inteiface. 

1 18, A process control system acconling to any of Claims 1 1, 12, 13, 14, 15 and 16 wherdn the 

2 software system ftuth^ indudes: 

3 a configuration program for oonfigoring the function blocks and installing the function blocks on the 

4 pluality of distributed oontrolleiSg the distribotedcontraUersrets^^ 

5 ^. until reconfigured. 

1 19. A process conlrd system according to any of Claims 11, 12, 13, 14, 15 and 16vdKreinthe 

2 jdmality of function blodcs is configured into a communication seivices hierarchy including: 

3 a remote object comnnmications (ROC) levd far comnumicating messages between two fi^^ 

4 blodcs in a same controller and between two fimction blodcs in difierem controlleis, and 
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5 a low levd communications level for inteifacing with communications hardware and transmittiog 

6 messages across the communications hanhvare. 

1 20. A compotapiogram product conqnising: 

2 a oonqiaiter usable medium having computable leadable code embodied therein indudiqg a piocess 

3 control system (100) for controlling a phuality of field devices of multiple dififeieni field 

4 device t|fpes including standard-protocol fidd devices (6) and nos-standaid-piotocol field 

5 devices (12), the process control system induding a plurality of distributed controllers (110) 

6 coined to the field devices^ the executable program code comprising: 

7 a softwaro s>ystem i n du d in g a plurality of function blocks (522) defined in a standaid protocol, the 

8 fimcdonbiodcs being selectively installable and operative on ones of the plur^ 

9 distributed controllers for sdectively controlling a standard-protocol field device and a non- 
- 10 standaid-protocol field device. 

1 21. A process control system (100) comprising: 

2 a field device; 

3 a omtroller (1 10) coupled to the fidd device; 

4 a workstation (102) coupled to the controller, the workstation inchiding a user interlace (300); and 

5 a software system implementing a control strategy for the process control system, the control 

6 strategy bdng selectively defined, created, modified, and apportioned via the user interface 
^ into a phirahtyofcontrol strategy modules, and the plurality ofoontrol strategy modules 

8 being selectively disuibuted among the fidd device, controller and workstation, the control 

9 strategy modules operating mutually indqien^ntly and in parallel. 

1 22. A iwocess control system (100) comprising: 

2 afidddevioe; 

3 a oontiol means coq>led to the fidd device for controlling the fidd device; 

4 an intetfoce means coupled to the contrd means for interiaciiig the control process system to a user; 

5 and 

6 a control strategy means for defining, creating, modifying, and implementing a process control 

7 strategy under direction of the user, the user sdeccivdy ^)portioning the control strategy 

8 means into a plurality of controlsttategy modules, and the user selectively distributing the 

9 control strategy modnles among the fidd device, control means and interface means, the 
contnilstxalegy modules operating inutuallyirulq^etidently and in paralleL 

1 23. A process control system according to dther Claim 21 or Claim 22, wherein: 

2 the software systmforther includes a user iittei^ue for iiiterikcing the process 

3 user, and 
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tlie control strata is selectively defined, created, modified, and appcmioiied, and the jdmali^ of 
control strategy modules sdectivdy distributed by the user. 

24. A process control system acoor^ng to either Claim 2 1 or Claim 22, wheieia* 
the fidd device indudes a control doncnt; and 

the software system indudes a control strategy module that is distrilmted to the field device control 

jJi»tni*ti[f 

25. A process control system according to dther Claim 21 or Claim 22 wherdm 
the field device is a Heldbus staiidard device iricluding a control dement; and 

a control strategy module is distributed to the control dement and operates selectively as a Fiddbus 
standard fimction Mode or a custom^ nscr-d^ned control module. 

26. Aprocess contnil system according to either Qaim 21 or Claim 22 whofdn the soi^^ 
liiitha: indudes: 

a oonfiguratioii program for defining, creating and configuring the control strategy modules and 

installing the control strategy modules among the fidd device, ooiUroller and workstation, 
the distributed controllers retaining the configuration until reconfigured. 

27. A pn)cess control system according to either Claim 21 or Claim 22» wherein: 

the control strategy modules are selectively defined, modified, and created by a user creating custom 

oontrol strata modules; and 
the control strategy modules are selectivdy distnbuted bj transferring a selected control strategy 

module to a selected one of the fidd device, controller and woikstation. 

28. A process control system according to either Claim 21 or Claim 22 wIkhcui the plurality of 
Gontrol strategy modules are configured into a communication services hierarchy indoding: 

a remote object communications (ROC) levd for communicating messages betwem two control 

strategy moddes in a same controller and between two oontrd strata modules in different 
controllers, and 

a low levd communications levd for interfadng with communicatioiis hardware and transmitting 
messages across the communications hardware. 

29. A method of operating a process control system (100) induding a distributed controller (1 10) 
and a distributed fidd device coiiq)rising the steps of: 

executing process control operation^ 

executing an editor program during execution of the process control system q)erations; 
using the editor program, defiiung a oonttol strategy indwdhig . ibe steps of : 
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6 building a plurality of function blocks (522) and conHol modules (440); and 

7 downtoading us^-specificd function blocks and control modules selectively among the 

8 distributed controller and the distributed field device; 

9 executing the function blodcs and control modules distributed to the controller and distributed to the 
10 field device nnrtuallyindq>endent]y and in parallel 

1 30. A computer program product for use in a process omtrol system ( 100) induding a fieid device;, a 

2 comroUer (1 10) coi^ied to the field device, and a \imksiation (102) coupled to the Gontroller, the con^nter 

3 program product conq>rising: 

4 a Gonqmter usable medium having computable readable code embodied therein hichiding a software 

5 system implementing a control strategy for the process control system, the control strategy 

6 bdog sdectivelbir definable, crcataft>le, modifiable, and apportionable into a plurality of 

7 control strat^ modules, and tfaepluiality of control strategy modules being selectively 

8 ^ distributable among the field device, controller and woikstation, the c^ 

9 modules operating imituallyindc|}endently and in parallel 

1 31. A process control system (100) oompnsing: 

2 a fidd device including a source of diagnostic information; 

3 a controller (110) coupled to the field device; 

4 a woricstation (102) coupled to the controller and includiiig a user inter&ce (300X and 

5 a software system implementing a diagnostic monitoring and di^l^ program for the ]»ocess control 

6 system, the diagnostic monitoring and display program including: 

7 a plurality of diagnostic modules selectively defined and created via the user inteiface for 

8 access using the diagnostic monxtoiing and display program, the pluralitv of 

9 diagnostic modules upon creation being selectively distributed among the field 
^® device, the controller and the workstation, the diagnostic modules operating 

1 1 mutnalty independently and in parallel accessing the source of diagnostic 

12 infotmatioi^ and 

1^ 3 display routine for accessing diagnostic information from the plmali^ of diagnostic 

1^ modules and displaying the diagnostic information accessed firom the phnali^ of 

15 diagnostic modules uniformly for all diagnostic modules in the process control 

1^ system so that the diagnostic information relating to a process that operates both in 

l'^ the controller and in the field device is displayed in the same manner regardless of • 

18 the source of theidiagnostic informatioa 



1 

2 
3 



32. A process control qrstem (100) comprising: 

afield device including a source or diaenosDC information: 

a contriver (110) coi9>led to the field device; 
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4 a woikstation (102) coupled to the controUer and incltidiiig a user intei&ce (300); and 

5 a software ^^stem in^lementing a diagnostic monitoring and display program for the process control 

6 system, the diagnostic monitoring and display program including: 

7 a plurality of control modules (440) for selectively implementing a process control strategy, 

8 a ploraliQr of diagoosticBiodulessdectively defined and cxeatBdvm 

9 access asing the diagnostkinonhoring and display program, the phi^^ 

10 diagnostic modidesiiponGfeaticmbetiig selective]^ distri^ 

1 1 device; the oontndler and the workstation, the diagnostic modolcs opezating 

12 mutnaUy indq)endaitfy and in paialld accessing the source of diagnostic 

13 infonnatioi^ and 

14 r a di^lay routine for accessing diagnostic information from the plurality of diagnostic 

15 moduks and a control scheme firom the phirali^ of control modules and for 

1^ respectively displaying the diagnostic inibtnnation accessed fiom the plurality of 

diagnostic modules and the control strategy aimssed from the plurality of c^ 
modules so that the diagnostic information and the control information are 

19 accessed in the same manner. 

1 33. A process conuol system (100) comprising: 

2 a plurality of field devices; a field device of the plurality of iield devices including a source of 

3 diagnostic information; 

4 a phnaUty ofcontndlers (1 lOX a controller of the plurali^ of controllers being coiqiled to a field 

5 device of the plurality of field device^ 

6 a workstation (102) coupled to the conuoller and including a user inter&ce (300); and 

7 a software system implementing a diagnostic monitoring and display program for the process control 

8 system, the diagnostic monitoring and display program including: 

9 a pluraliQr of diagnostic modules selectively defined and created via the us^ interface for 

10 access using the diagnostic monitoring and display program, the plurali^ of 

1 1 diagnostic modules iqion creation beiiig selectively distributed among the field 

12 device^ the ooittrollets and workstation, the diagnostic modules q)erating 

13 mutually indq>endcntly and in parallel; and 

14 a display foutinc for accessing diagnostic information firom the plurality of diagnostic mndnli*; 

15 operating mutually indepcndentiy on the field devices, the controllers and the workstation 

16 s ; and diqilaying the diagnostic information accessed from the plurality of diagnostic modules 

17 unifbtmfy so that the diagnostic information relating to a process that operates more than 
1^ one of the field devices, the controllers and the woikstation is displayed as being generated 
19 at a sin^e location. 
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1 34. A process control syslem (100) 

2 apl™ali«yofficWdevicc^afieWdeviceQf the plural^ 

3 diagaosticinfoimaliaii; 

4 a pluialitf of contrd means for controlling a field device, a control means of the phnalitf of cootrol 

5 means being coupled to a field device of the pimality of field device^ 

6 an inters means coupled to the phnality of control means for iwtMrf^'ng the control process 

7 system to a user, 

8 3 <^8°ostic means for implementing a process control strategy, the diagn^ 

9 selectively defined and created as a phuali^ of diagnostic modnles, the plurality of 

^ ^ diagnostic modules i^on creation being selective^ distribated among the fidd device, 

11 control means and imofiwe means, the diagnostic modules opeiatiiig mutually 

1 2 ind^endently and in parallel; and 

1^ a display means for accessing diagnostic information fi:om the plurality of diagnostic means 

operating mutually indqjendently on the field devices, the control means and the interlace 
means and displaying the diagnostic infiramation accessed from the plurality of diagnostic 

^ ^ modules nniformly so that the diagnostic information relating to a process that operates 

^'^ tnoie than one ofthefidddevioes, the control ineans and the inteificerneans is d^ 

1^ as bong generated at a sirigle location. 

1 35. A process control system (100) con^)rising: 

2 a field device including a source of diagnostic information; 

3 a controller (110) coupled to the field device; 

4 a mrksution (102) coupled to the controller and induding a user imerface (300); and 

5 a softwaro system implementing a diagnostic monitmng and display program for the process control 

6 siystem, the diagnostic numitorittg and displagr program inchuBng- 

7 a control strategy for the process control system, the control strategy beiiig selectively 

S apportioned into a plurality of control strategy modules and selectively distributed 

9 among the field device, controller and workstation, the control strategy modwles 

1^ operating mutually independently and in parallel; 

a phiraUty of diagnostic modules selectively defined and created via the user interfeoe for - 

^ ^ access nsiiig the diagnostic monitorir^ and display program, the phirality of 

<fiagii05ticmodEdesi9Qncreaticmbeh|gselectivdty 

^ ^ device, the oonlndlar and the woikstafion, the diagnostic modules opcratiog 

»iituallyindq)CDdenayandinparaUdacGesaaigthesour^ 

16 information; and 
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a display nmdne for accessing diagnostic infonnatioii from the pliizali^ of diagnostic 

1^ modules and displaying the control stxategy and the diagnostic infonnation 

accessed from the plurality of diagnostic modules onifoimly so that the diagnostic 

20 inf<nmation relating to a process that operates both in the controUer and in 

21 field device is displayed as being geneiated at a siniJelocatioa 

1 36. Apiocesso(mtrQlsystemaocordiiigtoaigrafClaims3I,32,33,34,^ 

2 the plurality of diagnostic modules are selectively defhied and created, and selectively distiibiited by 

3 . a user. 

1 37. A process control system according to aity of dainis 31, 32, 33, 34, and 35, wherein: 

2 the field device includes a control element; and 

3 a diagnostic module of the phuality of diagnostic modules is distributed to the field device and 

4 monitors a ctmdttion or status ofthe control dement 

\ 38. A process conUol system according to any of Claims 31, 32, 33. 34, and 35, further conq>riang: 

2. a network coupled to the controller; and 

, 3 an external node coiq)led to the controller through the n^ork so that device infonnation including 

4 realHime data, history information, event statistics, configuration data and diagnostic 

5 infonnation are accessed using network standard comrounicatians. 

1 39. A oon^ter program produa comprising: 

2 a computer usable medium having computable readable code embodied therein for controlling a 

3 process control system (100) including a source of diagnostic information, a controller 

4 coupled to the fidd device, and a workstation (102) coupled to the controller and including 
^ a user iDteriace (300), the executing program code implementing a diagnostic monitoring 

^ ; and display program for the process control system, the diagnostic monitoring and display 

7 program inchiding: 

5 a plurality of diagnostic modules selectively defined and created via the user im 

^ access using the diagnostic monitoring and display prograrn, the plurality of 

^0 ; diagnostic modules upon creation being selective^ distrftuted amcmg the field 

II ^ device, the controller and the workstation, the diagnostic modules operating 

^^ y. mutually independently and in parand accessing the source of diagnostic 

13 infonnation; and 

1^ a di^lay loutiiie for accessing diagnostic infiirmation from the plurality of diagnostic 

I ^ modules and displaying the diagnostic infonnaticm accessed from the plurality of 

diagnostic inodules uniforin]^ for aU diagnostic niodules in the imoesscmitro 

I^ system so that the diagnostic information relating to a process that operates both in 



9 



-94- 

I ^ controller and in the fidd device is displayed in the same manner regardless of 
19 the source of the diagnostic infonnation. 

1 40. A oonqmter program pioduct comprising: 

2 a amqmter usable medium having coaqmtable readable code embodied therein for controlling a 

3 process control system ( 1 00) including a field device having a source of diagnostic 

4 infimnation, a controller coqpled to the field device, a wcnkstation (102) coi^led to the 

5 oontroUer^ and a user intei^ (3 00), the computable readable code in^lonenting a 

6 diagnostic monitoring and display program for fine process control system, the diagnngric 

7 monitoring and di^lay program including: 

S a plurality of control modules (440) for selectively implementing a process control strategy; 

9 aphualityof diagnosticmodulessdectively ctefined and created via the user intei&ce for 

1^ access using the diagnostic moutoring and display program, the p^^ 

II ^giuisticnM>dulesi^n creation bemgselectivety distributed^ 

12 device, the controller and the woikstation. the diagnostic modules operating 

13 mutually independently and in parallel accesang the souroe of diagnostic 

14 information; and 

15 a display routine for accessing diagnostic infonnation from the phnality of diagnostic 
1^ modules and a control scheme fxxm. the plurality of control modules and for 

1^7 respeclivdydisi^aying the diagnostic infonnation accessed from the phindiiy<^ 

1 ^ diagnostic modules and the control strategy accessed from the plurality of control 

19 modules so that the diagnostic infonnation and the control information are 

20 accessed in the same manner. 

1 41 . A control system for controlling a process comprising: 

2 a controller co«q>ied to the process and 

3 a software system executing <m the controller and implememing a control strategy for controlling the 

4 process, the control stiat^ being defined |yy a layered hierarchy of modules including 

5 elemental modules containing exchisively one or moro primitives and conqwsite modules, 

1 42. A inrocess control system (100) focontrolting a plurality of £b^^ 

2 system comprising: 

3 a plurality of distnlrated controDos (1 10) cwipled to the field devices for controlling a process; and 

4 a distributed software system executing on the phirality of distributed controllers and inq)lcmenting 

5 a control strata for contndling the process; the oontrd strata being defined by a lay^ed 

6 hierarchy of modules distriboted for execution among the phuafity of distributed 

7 controUer^ the hioardiy of modules including demental modules oontainii^ exchisivdy 
S one or more primitives and conqxisite modules. 
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1 43. A process oontid system (100) compnsiiig: 

2 a phuali^ of field devices; 

3 a plara% of distributed comrolleis (110) coupled to the fidd devices for amtroUing a piocess; and 

4 a distributed software system executing on the pinrality of distribnted controllers and tiriptenHmttng 

5 a control strategy for controlling the process, the control strategy being defined by a hymd 

6 hierarcliy of modules distributed for ^cecution among the phmdity of distributed controlleis 

7 and plurality offidd devices, the Wcran*y of modules inchidin 

8 containing exclusively one or more primitives and comporiteinm 

^ A amtiolq^stcm for controlling a process under direction of a user, the control 

2 comprising: 

3 a controller (1 10) coiq»led to the process; and 

4 a software system executing on the controUer and implementing a control strata for controlling the 

5 process, the control strategy being defined by a plurality of control modules (440) which are 

6 Objects of a container dass, a control module of the plurality of control modules having a 

7 specified task and a jnedefined external interface, the control module being encapsulated in 

8 the software ^em aiid accessed through the predefined extemal interfeces so that the 

9 control module is user4nodifiable. 

1 45. A control system according to any of Qaims 41, 42, 43, and 44 wherein: 

2 the process includes a fidd device; and 

3 an demental module is an demental fimction block defined in accordance with a Hddbus standard 

4 protocol. 

1 46. A control system according to any of Gaims 41, 42, 43, and 44 further comprising: 

2 a user intex^ coqjled to the controUer for sped^g the control strategy, the control strategy 

3 bdng nser-spedfied by a module type of constiment demental modules and composite 

4 modules, by interconnections betwera the ccmstituent modules and by ii^mt/ ou^t 

5 connections ofthe constituent modules. 

1 47. A control system according to Gaim 46wherdn: 

2 the user inteifecc for modifying the control strategy is in^lemented in a plurality of process control * 

3 programming languages. 

1 48. A comrGl system according to any of Gaims 41, 42, 43, and 44 wherein the software system 

2 fimher indodes: 
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a GonfigmatiQii program fiir <tefiiung the oontnd strategfr and instaUing the control strategy oa the 
controll^, the controlla retaining the configuratiQn until leconiigured. 

49. A computer program product comprising: 

a conqjutcr usable medium having conqratable readable code embodied thcardn for controlling a 
process contfol system (100) for controlling a plurality of field devices, he process control 
9d«m including a phiralitf of distributed controlte 
oontiDlIiiig a process, the computable readable code iiii;?hiding- 

a distributed sofhrare qstcm executing on the plurality 

a control strategy for controlling the process, the control strategy being d^ned by a layeted 
hierarchy of modules distributed for execution among the plurality of distributed 
controllers, the hierarchy of modules inchiding elemental modules containing exclusively 
one or moro primitives and conqyosite modules. 

50. A conq>utef program product comprising: 

a conqmter usable niedhim having comput^le readable code embodied therein for controlling a 
process control ^cm ( 1 00) inchiding a phnality of fiehi devices and a plurality of 
distributed controllers (1 10) coupled to the field devices for contivdling a process, the 
computable readable code indnding: 

a distributed software system executing on the plurality of distributed controllers and implementing 
a control strategy for controlling the process, the control strategy being defined by a layered 
hierarchy of modules distributed for execution among the plurality of distributed controllers 
and the plurality of field devices, the hierarcby of modules iiwluding elemental modules 
containing exctosivety one or more primitives and composite modules. 

51. A process contrcJ system (100) comprising' 
a process; 

a plurality of controllers (1 10) coi5)led to the process; 

a workstation (102) coupled to the plurality of controllers and including a user interface (300); and 
a software system inchiding a network operating system and implementing a routine for 

automatically sensing a coimection of a controller to a network and incorporating the 

controller into the network operating system. 

52. A process control systm according to Claim 5 Iwherdn the sofhvaresystm 

a sofhvare routine responsive to automatic sensiqg of a connection of a controller to the network fw 
automaticaUy configuring an iiiputAmtput (I/O) subsystem in a control system. 
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1 53. A process control qpstem according to Claim 

2 connection of a contioller to a network and tncoipoiating the controller into a netwoik operating system 

3 oonpiiscs: 

4 means for connecting a controller to the netwwk; 

5 n^eansqyerative in the connected controner for sending a 

6 assignment* the request being acoonqaniedty the controller m^ 

7 address; 

8 a network configuration service including: 

9' nieans for rcceiviiig the request to confirm; 

means for searching a table of configured devices a matching MAC address; 
means operative when the MAC address matdies for generating device and network 
information inchiding a network address from a device tM&, 
• means operative when the MAC address does not match for generating device and network 
infornmtioninduding a network address from MAC address>based default 
information and adding the default information to the device table; and 

16 ^ means operative when the MAC address does not match for assigning the connected controller 

1 7 under user control either as a new device added to the device table or as a device 

18 configuration previoudy existing in the device table. 

1 

2 the conttofi^l^a^^^^^^^^rom 

3 connecting a controller to the netwodc; 

4 sending, by the connected controller, a request to confirm a network address assignment, the 

5 request being accompanied by the controller media access control (MAQ address; 

6 receiving, by a network configuration sendee, the request to confirm and responding by performing 

7 thestqsof: 

8 searching a table of configured devices for a matphing MAC address; 

9 when the MAC address matches* geneiatiiig device arid network information'^induding a 
10 network address from a device table; 

n • when the MAC address docs not match, generating device and network information 

12 inchiding a network address from MAC address-based default information and 

13 adding the default information to the device table; and 

14 when the MAC address does not match, assigning the connected controller under user control either 
as a new device added to ibe ^we table or as a device corifiguration previous existirig i^ 




15 



16 the device table. 



1 55. A iiietlu)dofautomaticaIly configuring an ii^ut/oid^ 

2 con^ristng the steps of: 

3 intenogating an I/O Card at a user-qiedfied card position to dctennine a Card IVpe and a number 

4 ofl/O Ports in the I/O Caret 

5 dctennining whether the intenrogatedVO Card is preWott^ defined m 

6 if the I/O Caid is not previously defined in the engineering database; defining an I/O Card of a 

7 suitable type and I/O Ports of a suitable munber, the suitable type and number bdng 
S predetermined for the card position; 

9 mteiiogatingtheI/OPoitsofanI/OCardinaoc»rdanoewiA 

10 Type and a number of I/O Devices on the I/O Por^ 

11 if the I/p Port is not pieviousiy defined in the engineeri ng database for the port address, defini i|g an 

12 yO Port of a suitable type and I/O Devices of a suitable number, the suit^le type and 

13 . number being predefined; 

14 interrogating the I/O Devices in accordance vvith the Port Type to detennine a Device I^e; 

15 if thcI/O Device is not previously defined in the engineering database for the device a ddress, 
1^ WO Device qfa suitable type, the suito^^ 

I creatmg instrument signal tags (ISTs) for primaiy signal sources on the I/O Ports and the I/O 
18 . Devices. 

1 56. A method according to Claim 55»imther comprising the steps of:. 

2 ctetermining whether an I/O Card exists in the engineering database for the card position; 

3 if the I/O Card exists in the engineering database, dctemiining whether the Card Type in the 

4 engineering database matches the Card 1>pe sensed at the card position, 

5 if the Card Type in the engineering database does not match the Card Type sensed at the card 

6 position executing the steps of: 

7 generating a graphic notification of the miignigf rii; 

S interrogating a user to delerrnine whether the engineering database is to be changed t 

9 imdude the sensed Card 1^; and 
c^gi^g the Card lype in the engineering dataibase to 

II user. 

1 57. A method according to Qaim 55, fimhercontprising the steps of: 

2 determiniriig whether an IfO Port exists in the engineering database for the port address; 

3 if the I/O Port exists in the engineering dataibase, determining whether the Port Type in the 

4 engineeriiigdatstese matches the type ofthe sensed I/O Port sensed at the port ad 

5 lflhel^lrtl>pe in the engineering datd)ase does not match the type of the s^^ 

6 thestepsof: 
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7 f equesting adviseaicnt of the user to detenni ne whether the engmeermg dm^mse- is to be 

8 tq)dated to match the sensed I/O Port; and 

9 changing the Port Type in the engineering database to the sensed Port Type if requested by 
10' theusor. 



1 58. A method according to Gaim 55, further comprising the stqis of: 

2 dctennining whether an I/O Device exists in the engineeaing datahaga fm- tht^. Awk^ afVtr A«r 

3 if the yo Device exists in the engineeriqg database, detcnmining whether the Device Type in the 

4 engineering database matches the type of the sensed I/O Device sensed at the device 

5^ address; 

6 ifthe Device l>pe in the engineering database does not match the type of the sen^ 

T' executing the stqxs of: 

8 lequestiiig advisemoit of the user to detecmine \^etlier the cngineeiing database is to be 

9 updated to match the sensed I/O Device; and 
changing the Device lype in the engineering database to the sensed Device 



10 



11 requested by the user. 

1 59. A computer program product comprising: 

2 a oompttter usable medium having computable readable code embodied therein for amomatically 

3 sensing a connection of a contioDer to a netwodc and incorpoiating the oontioller into a 
netwoik q)erating s^em including: 
a routine for connecting a controller to the network; 

6 a routine for sending^ by the connected controller, a request to confirm a network address 

7 assignment, the request being accompanied by the controller media access ccmtrol 
8„. (MAC) address; 

9 a routine for receiving, by a network configuration service, the request to confirm and 

10 responding fay executing routines including: 

H a routine for searchiitg a table of configured devices for a matting MAC address ; 

12 a routine for determining when the MAC address matches, and for a nmfctiing 

1^ address generati^g device and netwoik information inctndiiig a netvrozk 

14 address fiom a device table; 

15 a routine for d^ennining when the MAC address does not match, and for a 
1^ - nonmatching address generating device and network information 
1^7 induding a network address fit>m MAC address-based default 

1^ infinmatioii and adding the default infonnatton to the device table; and 

1^ a iDutine for detenniiii^gvdiea the MAC address does not inatch, and for a 

20 nonmatching address assigning the coimected controller under user 
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2 1 control either as a new devi ce added to the device table or as a device 

22 oonfigmation pievioustsr existing in the device table. 

1 60. A computer program product con^iising: 

2 a compato usable medhmi having computaible readable code embodied therein for automatically 

3 configoring an nopit/oa^mt (I/O) subsystem in a control system comprising: 

4 a routine for intenogating an I/O Card at a user-specified card positm 

5 T^andannniberftfl/OPdrtsinthel/O Card; 

6 a routine for deteiminingviiether the interrogated I/O Card is previoosfy 

7 engineering database; 

8 a routine cqserative when the I/O Card is not previously defined in the engineering database 

9 and defining an I/O Card of a suitable type and I/O Ports of a suitable number, the 

10 suitable type and number bdng predetermined for the card position; 

11 a routine for interrogating the I/O Ports ofanyo Card in accordance with the C^ 

12 detomineaPortTypeandannmberof I/O Devices on the I^ Port; 

13 a routine operative v/hcn the I/O Ptort is not previously defined in the engiheemig dataliase 

14 for the port address, the routine defining an I/O Port of a suitable and I/O 

15 Devices of a suitable number, the suitable type and number being predefined; 

1^ a routine for interrogating the I/O Devices in accordance with the Port Type to determine a 

17 Device l^pe; 

1 ^ a routine operative when |he I/O Device is not previously defined in the engineering 

1 9 database for the device address, the routine defining an I/O Device of a suitable 

20 type, the suitable type lieiiig predefined; and 

21 a routine for creating instrument signal tags (ISTs) for primary signal sources on the I/O 

22 Pons and the I/O Devices. 

1 61. A process control system (100) comprisiiiig: 

2 a process; 

3 a plurality of devices coupled to the process; 

4 a communication network coq>led to the devices; 

5 a workstation (102) cov9)led tothe phnality of devices via the netwodcandincittdingaiiser inter£K» 

6 (30O);and 

7 a software syston executable on the network and im]dementing a routine for automatically sensing a 

8 connectionof a device to a network and placing the connected device in an accessible state 

9 for communicating with a user via the user interface. 



1 

2 



62. A CQUtrol system comprising: 
a network; 
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3 aidunditfcfdevioesocwpledtotliexietw^ 

4 a disliibiited oontrDHCT coiipled to the phualily of devices and cootiolling the phuality of devices 

5 acooiduig to a defined oontrol amfigoratioii, the distributed controUer including: 

6 a control logic for sensing a device that is connected to the network but not included in the 

7 defined control configuration; 

S a control logic for supplying initial interconnect information to the connected device; and 

9 a contnd logic for iq>loading configuration panuneters firom the connected device to the 

10 distributed controller. 

1 63. A process contn>l system aocoiding to dtherClaiin 61 cffQaint 62 wher^ 

2 fiirther con^nises: 

3 a routine for configuring the connected device in a netwoik control configuration of the plur^ 

4 devices. 

1 64. A process control system according to C3aim 63 wfaeian the routine for configpri ng the 

2 connected device fiuther conqidses: 

3 a user-interactive routine for detennining a device type of the connected device; 

4 a user*interactive routine for dfteimining a role of the connected device with respect to the process 

5 control system; ^ 

6 a user-interactive routine for assigning a physical device tag the determined role; and 

7 a user-interactive routine for verifying connection of the device to the network. 

1 65. A process control system according to Claim 63 wherein the routine for configuring the 

2 connected device further coniprises: 

3 a user-intoactive routine for initiating calil>ntting the connected device; and 

4 a user-interactive routine for configuring the device within an overall control scheme of the process 

5 control ^rstcm. 

1 66. A process control system according to either Claim 6 1 or Claim 62 wherein the software system 

2 fiirther conqnises: 

,3. a routine for commissioning the ooniiected device including: 

4 a user-interactive routine for assigning a physical device tag, a device address and a device 

5 identification to the oomiBCted device; and 

• 6 a user-ititeraGtrve routine for iiistaUiiig a control strategy to the digital deido^^ 



67. A method of configuring a control system con[q>rising: 
predetennining a configuration of devices coupled to a network; 



» ... 
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3 snismgaconiiccdontothenetwoxkofadeiioetliatisii^ 

4 configuratioi^ 

5 assigiuiig the connected device a standby address which allows access to device infonnation and 

6 configuration parameters ofthe connected device; 

7 commissioning the connected device into an opeiationai state in conummication with the control 

8 5y5tan;and 

9 configming the connected device in combination with the piedetermined oonfigoiation of devices. 

1 68. A method aoooiding to Claim 67 vtoeincommissiottiiig the connected device fi^^ 

2 compnsesi 

3 assigning to the connected device a physical device tag, a device address, and a device identification; 

4 installing a control strategy to the connected device; and 

5 placing the connected device in an operaticmai state in communication with the networic 

1 69. A inethodaax>fdiiig to Qaim 67 iniierdn configuring the coniiected device 

2 inteaogating the connected device to determine a device type; 

3 determining a role of the connected device in the context of the predeteimincd configuration; and 

4 assigning a physical device tag so that the determined role is set 

1 70. A con^iuter program product comprising: 

2 a confer usable medium having computable readable code embodied therein for configuring a 

3 control system including: 

4 a routine for predetennining a configuration of devices coupled to a network; 

5 a routine for sensing a connection to the network of a device that is not included in the 

6 predetermined configuration; 

7 a routine for assigning the connected device a standby address which allows access to device 

8 information and configuration parameters of the connected device; 

9 a routine for commissioning the connected device into an operational state in communication with 

10 the control ^em; and 

11 a rootine for configuring the connected device in combination ^nth the predetenmned configuration 

12 ofdevioes. 

1 71. A process control system (100) for controlfir^ a process according to a contrd strategy 

2 process control system comprising: 

a computer system including a processor, an input inter£u:e and a display coupled to the process; 
a field device coi^led to the process; 

a controller coiq;»led to the field device and communicatively coupled to the corqutcr system; and 
a software system including: 
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7 an interactive, nser-diiected process configmatixm program induding a plmality of control 

8 language editors for selecting the control strategy using a control language selected 

9 from a plurality of control languages, the process configuration program creating 

10 an executable control module and downloading the executable control module 

11 seleclivefy among the conq>mersystem» the field device, and the contr^ 

12 an executable control module selectively created, downloaded and executed, the control 

13 module being configurable by the process configuration program to configure a 

14 cQntrd language execution engine. 

1 72. A process conlrd system (100) comprising: 

2 a field device; 

3 a controller (1 10) coupled to the field device; 

4 a workstation (102) coupled to the controller and having an interactive input intcthcc and a display; 

5 and 

6 a software system inchiding: 

7 a user interface (300) responsive to the interactive input inteiface for intofadhg the process 
g control system to a user; 

9 a routine for inq)lemcnting a control strategy for the process control system, the control 

10 strategy being selectively apportioned into a plurality of control modules (440) 

1 1 and sdectivei^ distribttted among the field device, the controller, and the 

12 woxkstation; and 

13 an interactive, user-directed process configuration program induding a plurality of control 

14 lai^^age editors for selecting the control strategy using a control language selected 

15 from a plurality of control languages, the process configuration program 

16 selectively creating the control modules implementing the control strategy, 

17 selectively apportioning the control modules, and sdectively distributing the 
Ig control modules among the field device, the controller, and the workstation for 
19 executing the control strategy. 

1 73. A process coiitrolsystan (100) for contn>Uing a ptundity of fidd devices of nni^ 

2 field device types» the process control system coinprising: 

3 aphnaility of controllers (110)Goapled to the fidd devices; and 
.4. a software system induding: 

$ a user inter^u^e (300) for inter&dng the process control system to a user, 

a plurality of control modules (440) selectivdy created, downloaded, and executed on ones 
oi the plurality of oontroIleis» the softwaro system for communicating with the 
mnhiple different field device types and for controlfing the mnltqile different fidd 
devices indqpendentty of contrd of contrd modules in other fidd devices; and 
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*® ^ interactive nscr-dixected process canfiguiation program includmg a plurality of conbol 

* * language editors for sdectively installing and configuring the contiol modules 

using a control language selected fiom a phiraliiy of control languages. 

1 '7'^- A process control system acooxding to Claim 71, Claim 72 or Qa^ 

2 the software system is distrifaned among the niocessor and the contmiiftr inrJiiHiiy 

3 ^ interactive ii^fot and diqilay routine execulable on the proce^ 

4 a plurafit^r of control language execution en^es executable on the controllea- for 

5 inqilemeating xespective languages of the plurality of control languages. 

1 75. A imx»ss control system according to Claim 71, Claim 72, or Oai^ 

2 a plurality ctf field devioe^ 

3 3 phira]ityofcontrolleisoou|ded to the field devices, wherein: 

4 the software system is disliilnited among the workstation and the plurality of controlleis and 
^ includes: 

6 an interactive input and display routine executable on the woikstation, and 

a phirality of control language execution engines selectively created, portioned, 

8 distributed, and ^ecutable on the plurality of controllers for implonenting the 

9 phirality of amtrol languages. 

1 76. A method for configuring a process control environment, the process control environment 

2 including a computer system having a processor coupled to a display device, the method miiip«ctT.g- 

3 providmg a phirality of instructional sections, an instructional section setting forth infoimation 

4 relating to configuring the process control environment; 

5 selecting a contnil language editor for defining a process control cnviro^^ 

6 activating the selected control language edhor; 

7 displaying on the display device, a sequence of configuration soeen presaitations relating to the 

8 instniction sections as directed in terms of the selected control language editor; and 

9 g»i*ng a user thnmgh the configuration of the process control enviionmOT^ 

10 configuration screen presentations; 

1 1 interactively oeating a phirality of indq)cndcnt control modules (440); 
*2 configuring the phnality of control modules to create a control ^tegy; 
13 •raosfe'M^ti'ccontrEd strategy to a selected controUcrex^ 

* ^ concspondiiig to the selected control language editor, the selected controUer 

decontrol strata indepttidentty of execution of otto 

1 77, A computer program product comprising: 
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2 a computer usable medium having computable readable code embodied therein for oontroUtng a 

3 process coutroi system (100) according to a control strategy, the process control system 

4 uu;hiding a coniiputer system with a processor, an inpm interface and a dispk^ 

5 the process; a field device coupled to the process; a controller coupled to the field device 

* ^conmnmicativelycaiqiIcdtotheoompQtersystem;andasaft«^system^l^^ 
7. including: 

S an intefactive, user«diiected process configaraiion program induding a phirality of contnd 

9 language editors for sdecting the cmitrol strategy using a control la^ 

fiom a plurality of control languages, the process configuration program creating 
an executable control module and downloading the executable control module 
^2 selectively among the conqrater system, the field device, and the controller, and 

^ executable control module selectively created* downloaded and executed, the control 
module being configurable by the process configuration program to configure a 
1^ control language execution engine. 

1 . 78. A computer program product comprising: 

2 a conq>uter usable medium having computable readable code embodied therein for managing a 

3 process control system (100) including a field device, a controller coupled to the field 

4 device, a workstation (102) coupled to the controller and having an interactive input 

5 intei&ce and a display and a software system inchiriing' 

6 a user inters (300) responsive to the imeractive iiqiut inteiface for intei^ng the process 

7 control system to a us^, 

8 a routine for implementing a control strategy for the process control system, the control 

9 strategy being selectively apportioned into a plurality of control modules (440) 

arui selectively distributed among the field device, the controller, and the 

11 workstation; and 

1^ ; interactive^ user-diiected process configuration program including a plurality of control 

1 ^ • language editors for selecting the control sttategy using a control language selected 

1^ frosn 8 plurali^ of control languages, the process configuration program 

1^ selective creating the control modules inq)leinenting the control strat^» 

- selectivety apportioning the control modules, and selectively distributing the 
control modules among the field device, the controUer, and the workstation for 

18.^ executing the control strategy. 



1 
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79. A GQDipula' program product 

a conqwiter usable mcdhwi having computaMe readable code embodied thmm far nrntwnm^^ ^ 
p]nra% of field dedoes of mubqite different fidd device types, the proce^ 
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4 ( 1 00) including a piuiality of oontroUeis (110) coupled to the field devices and a software 

5 system indading: 

6 a user inlei&oe (300) for inteifacing the process control system to a user, 

7 a i^uiality of control modoles (440) selectively created, downloaded, and executed on ones 

8 of the phualily of controlleis; the software system for communicating with the 

9 mu]tq>]e dififerent field device types and for controliing the multiple diffeient field 

10 devices indq)endently of control of oonlral modules in other field devices; and 

11 an interactive, user-diiected process configuration program including a plurality of control 

12 language editors for sdectively installing ami configuring the control niodnles 

13 using a control language selected fiom a i^ucalily of control languages. 

1 80. A conqrato^iaogiam product oonqnising: 

2 a conq)merusabkmjBdhunhaMi^cQiiqioCal>le readable code e^ 

3 . pnscess control enviromnott, the process control environm^ including a 

4 having a processor coupled to a display device and a software ^em including: 

5 a routine for providing a plurality of instructional sections, an instructional section setting 

6 forth infonnation relating to configuring the process control environment; 

7 a routine for selecting a control language editor for defining a process control enviromnent 

8 oonfiguraticm; 

9 a routine for activating the selected control language editor, 

10 a routine for displasyin^ on the dis|»hQrdeWce, a sequence of configuration screen 

1 1 presentations relating to the instraction sections as directed in teims c^the selected 

12 control language editor and 

13 a routine for guiding a user through the configuration of the process contra] enviromnent 

1 4 via the sequence of configuration screen presentations; 

15 a routine for interactively creating a plurality of independent control modules (440); 
1^ a routine for configuring the plurality of control modoles to create a control strategy, 

1^7 a routine for tiansfening the control strategy to a selected controller execudng a control 

IS language execution engine corresponding to the selected control language editor, 

1^ the selected controller executiiig the control strategy indq)enden4y of execution of 

20 other control strategies. 

1 81. A process control system (100) comprising: 

2 a field device including a soinoe of event fxmdition information; 

3 acontrdler(110)coiqdedtothefidddevic^ 

4 a woflEStation (102) onqyled to the controller and inchiding a userintoiace (300); and 

5 a software syston implementing an event condition mmiitoring and diq^lay program for the process 

6 control sysXeta, the event condition monitoring and display program induding: 
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aj^inali^of control mf)ddes (440) including event attritn^ 

selectively controlled and selectivdy distributed among the field devioe, the 
controUer and the \VQfkstation» the control modnles operating imitusdly 
indqiendently and in parallel aocnmuiating event condition information; 

a diqdaj lootine for accessing the event condition information fiom the phnality of control 
modnks and displaying the event comlition information accessed fiom the 
iduiality of control modules in an order of priorily sdecled 1^ 

a Gonfigination nmtine for user-selectively defining ^ 

the event attrihotes of the control modules, and for user selectively distributing the 
control modides among the field device, the controller, and the Tvoikstation. 

82. A process control sjrstcm according to ddm 81, wherein the sofh^ 

a nmtine for pnnuiig the event attributes with a cnnent alarm set subject to a current user 
responsihiliQr scq)e to begin accnmulatiiig an evem coum ixlien a 

83. A method for operating a process control system (100) comprising the steps of: 
defining a plurality of conditions as events, the events being associated with a plant area; 
activating an event journal for logging event conditions; 

configuring an alarm behavior including the steps of: 

creating an alarm attribute, the alarm attribute being selectively created in a control module 

or in an equipment module; 
selective^ disabling or enabling the created alarm attribute; 
selectively placing an enabled alarm attribute in an acknonledged state or an 

unadcnowledged state; and 
selectiveiy placing the alarm attribute in an active state or an inactive state; 
selecting a priority for the alarm attribute; and 
consolidattiig a plursditir of active alarm conditions into a subset of highest priority alarms. 

84. A conqmter program product oompiising: 

a conqmter usable medium having computable readable code mibodied thmin including a process 
control system (100) inchiding a field device including a source of event condition 
information, a controner coupled to the field device, and computer coupled to the controller 
and inchiding a user intcrfiaoe (300), the computer program product including an event 
condition monitoring and display program for the process control system, the event 
oonditiQn motutoring and display program including: 

a plurality of control modules (440) induding event attributes, the plurality of control 
modules being sdectively controlled and selectively distributed among the field 
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10 
11 



13 
14 



dcvfce, the omtraUer and the woikstadon, the control modules operatmg mutually 
imtq ie nrtMit ly and in parallel aocomulating event conditicm infonnation; 
* display Rratme fot accessing the emit condition tnfamiatiQn from the plurality of control 
modules and displayiog the event oondidon infonnation accessed fiom the 
pfanality of control modules in an oider of priority selected by the user, and 
^ configuration routine for user-selcctively defining and creating the control mo^hiles and 
' ^ ^ c'vent attributes of the control modules, and for user selecthrefy distributing the 

^ ^ conteol modules among the fisM device, the controller, and the wodstatian. 

1 85. A computer program product comprising: 

2 a computer nsablemedram having computable readable code embodied tfaeidn inchiding a process 

3 contn4 system (100) ftother induding: 

4 a routine for definii^ a plurality of conditions as events, the cvaits bdng aggftnat^^ ^ 
^ plant area; 

6 a routine for activating an event journal for logging event conditions; 

7 a routine for configuring an alann behavior including: 

« a routine for mating an alarm attribute, the alaim attribute being selectively 

^ created in a control module or in an equipment module; 

* routine for selectively disabling or enabUng the created ahum attribute; 
* ' 21 louiine fog selectively placing an enabled alarm attribute in an acknowledged 

state or an unacknowledged state; and 
* ^ a routine for selectively placing the alarm attribute in an active state or an inactive 

state; 

a routine for selecting a priority for the alarm attribute; and 
a routine for copsoUdating a plurality of active alarm conditions into a si:Aiset of 
hi£^est priority alarms. 

1 86. A con^wter program product acconling to dther Claim 84 or Claim 85 fti^^ 

2 a routine for priming the event attributes with a current alarm set subject to a cutraxt user 
responsibility scope to begin accumulating an evait count whwi a newus^logs-on. 



16 



3 



1 87. A conqnnerprogram product aoconJing to either Qaim 84 or Claim 85, further comprisi^ 

2 a routine for transitiomug between a plmalify of alarm attribute states, induding: 

3 a routine for sdectivdy disabling or enabling an alarm attribute, the alarm attribute bdng 

4 ™ an inactive and adauniledged condition wfaoi the alarm attiibote is di 

5 for configuring the alarm attribute with a bool 

^ active when the boolean anribote is true and the alarm is inactive whoi the 

^7 boolean attribute is true: 



wo 98/36335 



-109- 



PCTAJS98miS73 



a loudne for opdonaUjr invetting the sea^ 

and 

a routine for when the alarm attribute is enabled, selectively aduiowledging the alann 
attribiite or unadaioivkdging the alarm attrftmte. 

88. A con^mtex pro-am iirodDaaccoidl^ 
consolidating a plniali^ of actroe alarm condhiong iwi y^ ^^f fy 

a nmtiiie for ranktag an alatm condition in an order of decreasing cnder of precedence based on an 
ordered pdoriQr including: 

a routine for first ranking an unadcnoniedged condition with precedence over an 

acknotdedged condition; 
a ronline for second ranking a condition in order of High selected priority, Medium selected 

paanty, then Low sdected priority; and 
a routine for third ranking a condition in order of tone of detection ixith a newest 

timcstamp condition having a precedence over an oMer tii nggf amp f^dftipiL 

89. A computer program product according to dtherCaim 84 or Claim 85, wheremthe^ 
consolidating a plurality of active alarm conditions includes: 

a routine for user-level consolidation including: 

a routine for dispkying an alarm banner in a graphical user interiace (300); 
a routine for granting alann privilege over a one or more plant areas to a user; 
a routine for predefining an attrfbute container siqipoitiqg an alarms attribute; 
a routine for constructing a diq>lay rrfetendng the attribme container, and 
a routine for allowing access to highest priority alarms based on the diq>]ay referencing the 
attribute container 

90. A conq)uter program product according to either Oaim 84 or Claim 85, wherein: 
the conditions defined as events are conditions sdected from amorig the conditions of: 

alami^ 

alarm acknowledgniBnts; 

user changes induding attributes written by the user, methods invoiced by tte hsct. and log- 
in and log-out iterations by the user; 

configuration dianges to a run time system induding system installation and de-installatioii 
operations; 

Sequential Ftmction Chart (SFC) state changes; 
Operator Attention ReqiKSts (OARs); and 

misodlaneous events including noii*aiarm state tiansitidiis and equqmieat stale changes. 
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